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I.   INTRODUCTION 

During  the  early  1960's  when  the  dual  state  third  gen- 
eration computers  were  developed/th e  concept  of  virtual  iza" 
tion  was  born.  Little  did  one  recognize  the  potential  bene- 
fits or  rapid  transition  that  would  soon  take  place  in  the 
comouter  field  in  the  area  of  virtual  machines. 

Even  though  this  raoid  chanqe  and  increased  comolcxity 
may  lead  to  the  frustrations  expressed  by  John  Gosden/  Vice 
Presidents  Eauitable  Life  Assurance  Society  [18], 


"All  of  these  new  announcements  are  a  nuissance. 
rte'd  rather  be  qetting  on  with  doing  productive 
work  than  trying  to  keeo  aligned  with  the 
industry's  technolooy." 


However/  the  virtual  machine  concept  has  arrived  and  is  here 
to  stay.  Robert  P.  Goldberg  [111  notes  that 


"Virtual  machines  have  finally  arrived.  Dismissed 
for  a  number  of  years  as  merely  academic  curiosi- 
ties/ thev  are  now  seen  as  cost-effective  tech- 
niques for  organizing  computer  systems  resources 
to  provide  extraordinary  system  flexibility  and 
support  for  certain  uniaue  applications." 


and  Phil  Rook m an ,     President*  Innovation  Data  Processing  [181 
satirically  comments 


"Virtual  computing  is   complicated/   but   if   it's 
simplicity  you  want/  Qet  a  bank  of  1  a 0 1  * s .  " 


The  current  state-of-the-art  cf  virtual  computing  is  still 
in  its  infancy  and  its  potential  is  ripe  for  tapping*  esoe" 
ciallv  in  an  educational  institution. 
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In  the  fall  of  3  9  7 '4  and  parly  197  Sf  the  Naval  Postgradu- 
ate  School  acaui  red  two  Digital  Equiornent  Corporation 
PDP-11/50  computers  as  a  part  of  the  Signal  Processing  and 
Disolay  Research  Facility.  It  will  also  serve  as  a  valuable 
tool  for  the  computer  science  student. 

With  the  enchancement  of  virtual i  z  a  t  i  o  n  »  this  comouter 
system  would  increase  in  both  flexibility  and  Potential 
uses.  Virtual  machine  systems  can  be  used  to  resolve  a 
number  of  problems  that  face  a  student  of  computer  science. 
All  students  could  be  given  their  own  virtual  computer  for 
exploring  new  ideas  and  concepts.  The  student  ecu  la  imple- 
ment and  test  software  from  the  basic  hardware  level  to  the 
operating  system  level  without  the  fear  of  destroying  or 
interfering  with  the  real  system.  Courses  can  be  made  avail- 
able where  the  fundamentals  of  advanced  software  and  the 
design  and  analysis  of  operating  systems  are  ace  cm  pi  is  tied  in 
a  'hands-on'  environment. 

Besides  an  educational  need  for  virtual  machine's  there 
exists  the  problem  of  security  and  privacy.  Computer  tech- 
nology has  soawncd  a  whole  new  field  of  crime  and  generated 
a  series  of  p  r  o  b  1  e  t  s  for  both  designers  arid  users  of  infor- 
mation systems.  There  are  truly  very  few  systems  that  can 
be  classified  as  secure.  Particularilv  in  the  military  en- 
vironment/ security  is  a  ever  present  problem  and  a  major 
concern  of  students  whe  will  leave  this  educational  insti- 
tute and  work  in  a  military  computer  installation.  The  v  i  r  - 
tualized  computer  holds  areat  promise  as  the  solution  to 
this  ever  growing  problem.  It  would  for  e x a m p 1 e t    be  possible 
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for  the  POD-11/50  to  int°rqrate  classified  and  unclassified 
processes  without  degrading  the  performance  of  the  system 
and  without  the  fear  of  possible  compromise.  It  would  also 
eliminate  the  the  current  locked  door  'monoprocessing'  en- 
vironment policy  for  processing  classified  jobs. 

Another  need  that  can  be  solved  bv  usinq  a  virtual  com- 
puter is  in  system  development.  New  enhancements  to  the 
operating  system  could  be  throughly  tested  and  debugged  in 
'day  light  hours'  and  in  a  multiprogramming  environment 
before  being  place  'on-line'.  The  concept  of  virtual i  z  a  t  ion 
is  truly  an  exciting  area  of  computer  science  and  one  in 
which  the  effects  on  the  data  processing  community  are  just 
begi  nn  i  ng._ 

The  remainder  of  this  thesis  is  divided  into  five  addi- 
tional chapters. 

In  chapter  II,  the  background  and  principles  of  visual- 
ization a^e  explored  to  develop  a  basic  understanding  of  the 
virtual  machine  and  the  current  terminology  associated  with 
it.  A  glossary  (Appendix  A)  is  provided  for  the  convenience 
of  the  reader. 

Chanter  III  gives  a  summary  of  the  architectual  design 
of  the  PDP-11/50  family  of  computers  and  highlights  some  of 
the  unsu i t ab i 1 i t i es  of  this  tyoe  of  architectural  design 
for  virtual izati on. 

Chanter  IV  presents  the  problems  of  virtualizinq  the 
PDP-11/50  and  examines  some  possible  solutions  to  these 
problems  to  include  recommended  milestones  towards  the  ulti- 
mate goal  of  a  fullv  virtu alized  PDP-11/50, 
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The  selection  of  an  aoproach  to  vi  rtual izp  the  PDP-11/S0 
and  implementation  of  this  aporoach  is  o resented  in  Chapter 
V.   A  user  manual  (Appendix  D)  is  also  provided. 

Both  chapters  IV  and  V  are  self-contained  and  those  who 
are  knowledgeable  about  current  virtual  machine  anplications 
and  technology  should  be  able  to  s  k  i  p  directly  to  these  sec- 
tions. 

Chapter  VI  summarizes  the  conclusions  of  this  implemen- 
tation and  contains  some  suggestions  for  further  develop- 
ment . 
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II.  VIRTUAL  ^ACHINFS  -  P&INClPLfc'S  AN0  7  ERMI  NOLOGY 


A.   PRINCIPLES  AND  TERMINOLOGY 

The  virtual  machine  can  basically  be  pictured  as  an  ima- 
ginary cony  of  some  real  existing  computer  system  but  with 
the  capability  of  executing  real  programs  .  This  unioue  and 
rather  new  idea  has  introduced  to  the  computer  world  the 
concept  of  mu 1 t i -env i ronmen t i ng  as  compared  to  multi- 
programming and  multi -processing.  In  extendi  no  the  basic 
idea  of  the  virtual  machine*  one  is  lead  to  the  realization 
that  one  real  comouter  can  create  many  imaginary  computers* 
each  of  which  may  have  different  hardware  characteristics 
and  devices.  In  addition,  each  imaginary  machine  may  support 
different  operating  systems. 

"Basically  a  virtual  machine  is  a  very  efficient  simu- 
lated cooy  (or  copies)  of  the  bare  host  machine  [13]".  A 
bare  ho^t  machine  is  simply  a  machine  without  its  accom- 
panied software*  i.e.  ooerating  system.  If  we  included  the 
operating  system's  instruction  set  (system  calls*  I/O's* 
etc.)  along  with  the  basic  hardware  instructions 
( MOV  *  BR* e t c . ) *  *e  have  introduced  the  instruction  set  for 
the  extended  machine  i.e.*  the  bare  machine  plus  operating 
system  is   the  extended  machine. 

The  virtual  machine  may  be  further  defined  as  an  effi- 
cient* isolated*  duplicate  of  a  real  machine.  It  first  must 
be  efficient*  meaning  that  the  proorarns  executing  under  the 
virtual  machine  should  basically  run  at  speeds  comparable  to 
execution   on  the  real  machine.   This  attribute  of  a  virtual 
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mac h in e  makes  it  reasonable  to  run  production  type  jobs  on 
the  virtual  machine. 

Ihe  efficiency  aspect  of  tho  virtual  machine  is  realized 
by  having  the  majority  of  instructions  of  a  program  running 
on  the  virtual  machine  executed  directly  on  the  real  host 
computer.  This  concept  rules  out  traditional  emulators  and 
complete  software  interpreters/  for  both  methods  demand 
total  interpretation  of  all  program  instructions. 

Second lyf  the  reason  the  virtual  machine  must  be  isolat- 
ed iron  the  rest  of  the  system  is  to  insure  that  it  has  com- 
plete control  over  managing  its  own  systems  resources/  and 
that  no  unintentional  interference  exists  between  the  real 
and  virtual  system. 

Finally,-  the  virtual  machine  must  produce  a  duplicate  or 
essentially  identical  environment  of  real  machines  to  make 
it  practical  to  run  real  jobs  on  them.  "Since  a  virtual 
machine  is  a  software-hardware  duplicate  of  a  real  exist im 
computer  system  there  is  always  the  notion  of  a  real  comput- 
er system  or  real  machine/  whose  execution  is  functionally 
eauivalent  to  the  virtual  machine  (13]."  If  one  must  modify 
a  job  to  be  executed  on  a  virtual  machine  because  the  virtu- 
al machine  is  slightly  different  from  the  real  machine/  then 
the  virtual  machine  concent  has  loss  its  beauty/  value/  and 
practicality  F  i  3]  . 

It  should  be  obvious  that  certain  tvpes  of  instructions 
can  not  be  allowed  to  be  executed  directly  but  must  be  simu- 
lated by  tho  virtual  machine.  The  job  of  identifying  a  n  rJ 
trapping   that   type   of   instruction   is   the   heart  of  the 


i  •> 


virtual  machine.  The  program  that  executes  on  the  r  <*  a  1  host 
machine  creation  the  virtual  machine  environment  is  called 
the  virtual  machine  monitor.  Its  function  is  to  be  the 
software  interface  between  the  real  system  and  virtual  sys- 
tem. 

Figures  1  and  ?  13]  illustrate  the  basic  differences 
between  the  conventional  computer  system  and  a  virtual 
machine  organization.  The  conventional  dual  state  extended 
machine  architecture  contains  only  one  basic  machine  inter- 
face which  can  supnort  many  user  programs  but  is  only  capa- 
ble of  running  one  privileged  software  nucleus  at  a  given 
time.  As  contrasted  in  figure  ?.  t  the  virtual  machine  ap- 
proach, the  virtual  machine  monitor  creates  additional  basic 
machine  interfaces  which  are  functionally  identical  to  that 
of  the  real  machine.  Thus  any  Drivilegeo  software  nucleus 
that  will  run  on  the  real  machine  will  execute  on  the  virtu- 
al machine.  It  is  interesting  to  note,  that  the  privileged 
software  nucleus  has  no  way  of  knowing  whether  it  is  beino 
executed  on  the  real  or  virtual  mac  nine. 

Figure  2  should  riot  imcly  that  the  basic  machine  inter- 
face supported  by  the  virtual  machine  monitor  must  be  ident- 
ical to  the  interface  of  the  bare  machine  that  the  virtual 
machine  monitor  runs  on,  i.e.  a  virtual  IBM  S  /  3  6  0  50  need 
not  be  produced  on  a  real  S  /  3  6  0  5  0  t  However,  when  the  inter- 
face is  not  identical  they  will  be,  at  the  minimum,  of  the 
same  com  outer  family.  /J  h  e  n  two  interfaces  are  completely 
different  ( 1 8 M  S/360  versus  BURROUGHS  6700)  then  emulation 
or   simulation   must   be   employed   to   map   the   one  system 
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architecture     into   another  different  architecture. 

The  question  that  might  b  p  logically  asked  at  this  ooint 
is:  "Are  there  any  restrictions  on  the  type  of  orograrns  that 
can  be  orocessed  on  a  virtural  machine?".  Surprisingly/ 
there  is  basically  only  one  type  of  program  that,  will  not 
execute  Droperly  on  the  virtual  machine  and  that  is  a  pro™ 
gram  with  timina  dependencies.  This  type  of  program  while 
once  popular  is  now  extremely  rare.  Reference  241  provides  a 
detailed  insight  into  this  area. 

The  virtual  machine  can  now  be  formally  defined  as  fol- 
lows [  2  a  1  : 


"A  virtual  computer  is  a  hardware-software  dupli- 
cate of  a  real  exist  inq  com outer  system  in  which  a 
statistically  dominant  subset  of  the  virtual 
processor's  instructions  execute  directly  on  the 
host  orocessor  in  native  mode." 


The  method  of  producing  a  virtual  machine  to  Meet  the 
above  stated  definition  may  vary  greatly.  The  method  would 
depend  on  such  things  as  the  specific  brand  and  mode'!  of 
com outers  the  degree  of  efficiency  require 6r  and  the  in- 
genuity of  the  programmer  of  the  virtual  machine  monitor. 
There  is  no  one  best  approach  or  method.  The  virtual 
machines  that  have  been  produced  to  date  though*  can  be 
categorized  into  general  types  depending  on  the  method  of 
implementation  [  3  r  1  3  r  1  4 )  . 

A  t  y  o  e  I  monitor  is  illustrated  by  figure  2 .  t^ere  the 
virtual  machine  monitor  runs  directly  on  the  bare  machine* 
where  as  the  type  II  monitor  (figure  3)  runr  on  the  extended 
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machine  under  an  operating  system. 

A  t  y  o  e  I  monitor's  only  functio n  is  to  produce  one  or 
more  virtual  bare  machines  which  will  support  any  operating 
system  that  the  real  bare  machine  would  support. 

The  type  II  monitor?  on  the  otner  hand?  can  take  advan- 
tage of  the  services  provided  by  its  operating  system*  For 
instance*  such  features  as  the  memory  management*  the  actual 
paging  mechanism,  and  I/O  operations  of  the  operating  system 
can  be  used. 

When  the  virtual  machine  is  identical  to  the  host  pro- 
cessor then  we  say  that  the  virtual  computer  system  is 
self-virtualizing.  A'hen  it  is  not  identical*  then  the  virtu- 
al machine  must*  as  earlier  stated*  be  of  the  same  processor 
family  as  the  host  machine  and  is  said  to  be  family  virtual- 
izing.  An  example  of  family  virtual i zing  is  an  IBM  system 
370/155  as  the  host  machine  which  is  supoorting  a  virtual 
system  360/50  machine. 

One  very  apparent  benefit  of  family  virtual izing  is  in 
upgrading  the  computer  in  a  data  processing  'installation. 
Here  the  old  system  could  be  virtualized  to  process  all  jobs 
that  have  not  been  reorogrammed  to  meet  the  new  systems 
requirements,  Peorogrammina  then  would  not  be  a  critical 
factor  but  could  be  accomplished  in  a  timely*  directed 
manner.  In  fact*  some  application  programs  which  are  pro- 
cessed very  infrequently  mav  never  pc  selected  for  repro- 
g  r  a  m  m  i  n  g . 

Recursive  virtu-alizina  is  when  an  additional  copy  or 
copies   of   the   virtual   machine  monitor  run  on  the  virtual 
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system  or  systems  that  have  been  produced  by  the  host  com- 
puter, we  have  then  in  effect*  produced  another  level  of 
virtual  machines.  Figure  4  illustrates  this  recursive  pro- 
perty* and  the  concepts  of  levels  of  virtual  machines. 

It  is  interesting  to  note  that  recursive  virtualizing  is 
supoorted  only  under  the  se 1 f - v i rt ua 1 i i i ng  type  system.  The 
main  reason  for  this  restriction  is  the  fact  that  the  virtu- 
al machine  monitor  is  tailored  to  interface  with  a  specific 
model  of  computer*  and  therefore*  it  is  only  possible  to  run 
the  monitor  when  the  identical  interface  is  produced. 

One  can  see  that  this  property  is  indeed  recursive*  for 
level  2  in  figure  4  is  another  virtual  machine  monitor  and 
could  have  in  effect  recursed  again  and  produced  a  third 
level  virtual  machine  and  so  forth.  Tests  have  successfully 
been  conducted  over  a  six  level  recursion  [12] • 

One  main  advantage  of  practical  importance  in  recursive 
virtualizing  is  the  ability  to  test  and  modify  the  virtual 
machine  monitor  itself  without  interfering  with  normal  pro- 
cessing. 


B.   BASIC  REQUIREMENTS  FOR  VIRTUAL  MACHINE  SYSTEMS 

Since  the  majority  of  instructions  of  application  pro- 
grams running  on  a  virtual  machine  are  going  to  execute 
directly  on  the  host  computer  without  any  software  interven- 
tion* a  method  must  be  derived  to  trap  only  those  "critical 
instructions"  that  must  not  be  allowed  to  be  executed.  Be- 
fore adaressing  this  trapping  process/  more  fundamental 
questions  should  first  be   considered*   namely   "What   is   a 
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critical  instruction?"  and  "How  can  one  identify  them?". 

Basically  the  third  generation  of  com outers  created  two 
distinct  processor  modes  of  operation  (privileged  -  'super- 
visor' and  nonprivileaed  -  'program').  The  supervisor  mode 
permitted  certain  'privileged'  instructions  to  be  executed 
which  are  denied  execution  in  tr>e  user  mode.  Privileged 
instructions  then  are  those  instructions  which  are  allowed 
to  be  executed  in  the  supervisor  but  not  in  the  orogram 
mode.  These  privileoed  instructions  typically  control  crit™ 
ical  system  features  such  as  testing  and  initiating 
input/outout  facilities  or  modification  of  address  maoping 
mechanisms.  When  the  user  requires  the  execution  of  a 
privileged  instruction  the  user  program  executes  a  suoervi~ 
sor  call  to  the  operating  system.  This  privileged  instruc- 
tion is  then  executed  on  behalf  of  the  user  program. 

Professor  Robert  P.  Goldberg  in  his  Ph.D  thesis  [131  on 
virtual  machine  architecture  defined  the  critical  instruc- 
tions as  the  following: 


"A  sensitive  instruction  is  an  instruction 
which*  because  of  3rd  generation  virtual  machine 
software  construction  wil'l  give  incorrect  results 
if  permitted  to  be  exec  uteri  directlv  on  the  host 
computer" . 


It  is  now  obvious  that  sensitive  instructions  encoun- 
tered in  the  virtual  system  cannot  be  allowed  to  execute 
directly*  since  the  execution  of  sensitive  instructions 
could  prevent  the  correct  interpretation  of  certain  instruc- 
tions. 

He  states  the  key  to  implementing  a  virtual  machine  on  a 
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third  generation  system  is  to  provide  complete  functional 
eoui valence  with  a  real  machine  without  allowing  the  direct 
execution  of  sensitive  instructions. 

Sensitive  instructions  are  divided  into  two  general 
types*  namely/  control  sensitive  and  behavior  sensitive 
i  nst  rue  t  i  ons . 

1.  Control  sensitive  instructions  are  those 
instructions  which  control  the  resources  and  en- 
vironment of  the  system.  Examples  of  such  instruc- 
tions are  those  which  attempt  to  change  available 
memory*  start  an  I/O  operation,  or  change  the  pro- 
cessor mode. 

2. .  Behavior  sensitive  instructions  are  those 
instructions  whose  execution  depends  upon  their 
location  in  real  memory.  An  example  of  such  an 
instruction  is  the  system /36Q  ERA  (load  physical 
address)  instruction. 

The  machine  instruction  reoertoire  of  the  host  computer 
system  must  be  individually  analyzed  to  determine  their  sen- 
sitivity. Each  instruction  should  be  questioned  as  to  wheth- 
er its  execution  could  produce  a  Dossible  erroneous  results 
if  allowed  to  execute  in  the  unprivileged  mode.  This  iden- 
tification and  analysis  appears  to  be  like  a  fairly  simple 
process*  but  in  reality  before  this  can  be  accomolished/  a 
thorough  understanding  of  both  the  machine  language  and 
hardware  characteristics  ti u s t  be  mastered. 


23 


Qnce  the  sensitive  instructions  have  been  identifed/   it 
is   now   possible   to   determine  if  the  computer  system  will 

supoort  a   virtual   machine.   Professor     Goldberg's   First 

Theorem  on  virtual  inability  gives  us  this  answer  [24]  . 


"THEOREM  1  :  For  any  conventional  third  generation 
computer/  a  virtual  machine  monitor  may  be  con- 
structed if  the  set  oi  sensitive  instructions  for 
that  computer  is  a  subset  of  the  set  of  privileged 
instructions." 


The  basic  philosophy  behind  Theorem  1  is  the  following. 
If  all  sensitive  instructions  are  a  subset  of  the  privileged 
instructions^  then  the  host  computer  has  a  very  convenient 
built-in  trapping  method.  Any  attempt  to  execute  a 
privileged  instruction  in  the  program  mode  will  generate  a 
machine  interrupt.  Therefore*  if  the  virtual  machine's 
privileged  software  is  running  in  the  program  state  then  an 
interrupt  will  be  generated  when  the  virtual  machine's 
operating  system  attempts  to  execute  any  privileged  instruc- 
tions. Since  the  sensitive  instruction  is  a  subset  of  the 
privileaed  instructions  set/  it  is  just  a  matter  of  checking 
to  see  if  the  privileged  instruction  causing  the  interrupt 
is  sensitive. 

This  class  of  interruots  can  then  be  turned  over  to  the 
virtual  machine  monitor  for  servicing.  If  it  is  a  sensitive 
instruction  that  generated  the  interrupt  then  it  will  be 
simulated.  If  not?  it  will  be  returned  to  the  host  operating 
system  for  execution.  Figure  5  illustrates  this  interaction. 
The  interested  re--) dor  should  refer  to  reference  124]  for 
proof  of  Theorem  1. 
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This  rather  simple  theorem  supri singly  proves  that  very 
few  third  generation  architectures  are  virtual izable,  for  it 
only  takes  one  instruction  to  cause  the  monitor  to  be 
forced  to  interrogate  all  instructions  to  prevent  the  execu- 
tion of  the  one  exception.  This  of  course  would  cause  the 
virtual  machine  to  lose  its  efficiency  and  value.  It  should 
be  realized?  however,  that  third  generation  computers  were 
not  designed  to  support  virtual  machines,  and  it  is  their 
dual  state  nature  that  brought  about  the  virtual  machine 
concept  in  the  first  olace. 

C.   HYBRID  VIRTUAL  MACHINE  SYSTEMS 

Since  the  majority  of  third  generation  computers  are  not 
virtual  i  2  a  b 1 e  the  hybrid- virtual  machine  monitor  was  intro- 
duced. Here  sensitive  instructions  are  further  classified 
into  two  groups  depending  on  where  they  can  be  located,  i.e. 
are  thev  only  located  in  the  supervisor  area  of  coding 
(supervisor  sensitive)  or  can  they  be  in  the  user  area  (user 
sensi t  i  v e ) ? 

Once  the  user  and  suoervisor  sensitive  instructions  are 
identified  then  Goldberg's  Third  Theorem  can  oe  applied, 
which  is  the  following  [?.'4]  : 


"THEOREM  3.  A  hybrid  virtual  machine  monitor  may 
Op  constructed  for  any  conventional  third  genera- 
tion machine  in  which  the  set  of  user  sensitive 
instructions  are  a  subset  of  the  set  of  privileged 
instructions." 


The  main  difference  then  between  the  virtual  machine  ani 
the  hybrid  virtual  machine  is  in  the  degree   of   instruction 
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interpretation,  Tn  the  hybrid  virtual  machine  all  instruc- 
tions/- privileged  or  not,  in  the  virtual  supervisor  mode  are 
interpreted.  User  sensitive  instructions  will  be  trapped  as 
previously  mentioned. 

Figure  6  is  an  overview  that  compares  in  struct  ion  in- 
terpretation versus  direct  instruction  execution  for  normal 
processing,  virtual  machine  processing,  hybrid  processing, 
and  for  complete  simulation.  It  should  be  remembered  that 
the  more  time  spend  in  interpretation  the  slower  the  execu- 
tion of  the  job. 

D.   THE  VIRTUAL  MACHINE  MONITOR 

The  virtual  machine  monitor  controls  the  overall  virtual 
machine  system.  The  monitors  main  functions  ere  to  create 
the  virtual  machine  or  machines,  to  monitor  and  allocate 
their  resources,  to  interrogate  all  trapped  instructions  for 
sensitivity,  and  to  simulate  the  execution  of  the  sensitive 
instructions. 

The  virtual  machine  monitor's  software  is  composed  aen- 
eral'ly  of  three  group s  of  program  modules  plus  numerous  con- 
trol tables  (figure  7).  The  three  oroups  are  the  dispatcher, 
allocator,  and  the  interpreters.  The  control  tables  depict 
all  the  virtual  machines  resources  available  and  their 
current  status.  These  tables  are  similiar  to  the  normal 
operating  system's  tables  and  control  blocks. 

The  dispatcher  is  the  too  level  control  module  of  the 
Virtual  machine  monitor.  It  is  the  initial  program  that 
receives   the   machine   interrupts   and   determines   if   the 


27 


REAL      MACHINE 


S.  I 


D.E 


VIRTUAL    MACHINE 


S.I 


D.E 


n 


n 


HYBRID     VIRTUAL    MACHINE 


S.I.    — 


D.E. 


SIMULATION 


S.I. 


D.E 


SOFTWARE  INTERPRETION    VS.    DIRECT   EXECUTION 


FIGURE      6 


28 


cc 
o 

h- 

o 

LU 

X 
O 

< 


< 

q: 


1 

<f) 

oc 

UJ 

H 

LU 

a: 

• 

LU 

r 

... 

z 

if) 
111 
_J 

© 

/ 

cc 

/ 

go 

0 

m 

/ 

< 

X 

o 

i- 

— ^ 

< 
Q. 

Q 

o 

q: 

V 

' 

\Z. 

"*■"■              J          \ 

o 

q: 

o 

o 

h- 

< 

o 

—1 

< 

N- 


LxJ 

CC; 

ZD 


__   -  . 


29 


instruction  that  is  trap p e  d  is  sensitive.  If  it  is  sensitive 
then  the  dispatcher  decides  which  modules  to  call  to  ser- 
vice this  action.  If  it  is  a  resource  request  or  a  resource 
modification,  then  the  dispatcher  will  invoke  the  allocation 
module.  If  the  action  calls  for  a  sensitive  instruction  to 
be  simulated  then  one  of  the  interpreter  modules  will  be 
cal led. 

The  allocation  module  is  the  main  keeper  of  the  control 
tables  for  the  virtual  machines.  It  is  through  this  module 
that  all  the  virtual  machine  devices  are  created  and  con- 
trolled, rthen  the  virtual  machine  monitor  is  suoporting  mul- 
tiple virtual  machines,  the  complexity  of  this  module  is 
significantly  increased.  It  now  must  keeD  track  seoaratelv 
of  the  individual  resources  of  each  virtual  machine. 

The  last  nroup  of  oroaram  modules  that  make  up  the  vir- 
tual machine  monitor  is  comoosed  of  many  individual  modules 
called  interpreters.  There  is  generally  one  interpreter 
routine  for  each  identified  sensitive  instruction.  Each 
interpreter  routine  will  simulate  an  instruction  execution 
by  changing  the  state  of  the  virtual  machine  so  as  to  re- 
flect its  actual  execution. 

All  software  -  be  it  an  operatina  system,  apolication 
program  running  u  n  d  p  r  the  ooerating  system,  or  a  stand-alone 
program  executing  on  the  virtual  machine  -  must  execute  in 
the  nonorivileged  program  mode  of  the  host  computer.  This  is 
essential  so  that  the  re  a)  machine's  interrupt  can  trap  sen- 
sitive instructions.  It  should  be  obvious  that  a  tyoe  I 
virtual   machine   monitor   must   execute   in   the  supervisor 
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stater  since  it  is  in  fact/  the  total  onerating  system  for 
the  real  hardware.  The  type  II  virtual  machine  on  the  other 
handr  has  a  choice  between  supervisor  and  prooram  state. 

If  a  tyoe  II  monitor  is  allowed  to  operate  in  the  super- 
visor stater  then  the  relationship  and  coordination  between 
it  and  the  onerating  system  must  be  carefully  thought  out 
and  designed  to  insure  that  there  is  no  unintentional  in- 
terference. If  the  monitor  is  executed  in  the  privileged 
moder  then  it  could  execute  within  itself  the  privileged 
instructions  that  may  be  requi  red  to  be  actually  executed 
after  either  being  trapped  or  requi  red  by  some  interpreter 
module.  It  would  thereby  save  the  time  of  requesting  and 
waiting  for  the  operating  system  to  execute  them. 

If  on  the  other  handr  the  monitor  is  running  in  the  pro- 
gram state  then  the  interface  problem  with  the  operating 
system  is  nonexistent.  All  privileged  instructions  that  Are 
required  to  be  executed  must  be  turned  over  to  the  operating 
system.  This  would  probably  require  some  additional  supervi- 
sor calls  to  be  added  to  the  system/  but  it  would  also  make 
the  virtual  machine  monitor  smaller  and  less  complex. 

E.   SOFTWARE  AND  HARDWARE  REQUIREMENTS 

The  hardware  and  software  requirements  of  the  host  com- 
puter system  must  meet  the  followino  criteria  to  adequately 
support  a  virtual  computer  system. 

1.   The  method   of   instruction   execution   of 
non-pri vi  ieged  instructions  in  both  supervisor  and 
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p  r  o  q  r  a  m  state  must  be  roughly  equivalent.  This  is 
important  because  the  ooeratinq  system  of  the  v  i  r  " 
tual  machine,  which  normally  operates  in  the  su- 
pervisor state,  will  be  executing  in  the  program 
state.  There  is  also  the  reverse  problem  of  the 
privileged  instruction  in  the  program  state  not 
causing  machine  interrupts.  For  example,  in  the 
POP  11  family  of  comnuters  certain  instructions 
are  iqnored  if  they  are  encountered  while  in  the 
program  state. 

2 .  A  method  of  automatically  signalling  the 
supervisor  when  the  virtual  machine  attempts  to 
execute  a  sensitive  instruction  must  be  available. 

3.  A  method  of  protecting  the  supervisor  and 
any  other  virtual  machine  must  be  available  to 
insure  isolation  of  all  systems. 

U .  The  host  computer  should  suoDort  a  page 
or  segmentation  type  virtual  me^orv  system  to  ade- 
quately give  the  virtual  machines  their  own  virtu- 
al memory  required  to  hold  its  virtual  operating 
system  olus  its  own  amplication  programs. 


F.   ADVANTAGES  AND  APPLICATIONS  OF  VIRTUAL  MACHINES 

The  advantages  of  a  virtual  machine  have  intentionally 
been  left  until  now,  because  many  of  the  benefits  can  be 
better  aporeciated  once  one  has  a  good  understanding  of  the 
concepts   and  workings  of  virtual  machines.  In  facte  because 
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virtual  machines  lo^d  themselves  to  so  many  practical  a  o  p  1  i  - 
cations*  it  is  felt  by  many  computer  experts  that  the  "next 
generation"  of  computers  will  be  specifically  design'  it o  sup- 
port virtual  machines. 

The  following  outlines  a  few  of  the  more   important   a  d  - 
vantaoes  and  applications  of  the  virtual  machine  [19]. 

1.  Softwa re  Development  For  The  System  Programs. 
Because   system  programs  cannot  run  under  the  normal 

operating  system  in  a  production  tyoe  environment*  most  sys- 
tem programming  work  must  be  accomplished  in  a  stand-alone 
environment*  and  generally  in  the  middle  of  the  night.  It 
also  causes  the  system  to  be  brought  down  which  interfers 
with  normal  processina  and  is  wasteful  of  system  resources* 
not  to  mention  the  inconvenience  for  both  system  and  appli- 
cation programmers.  Using  a  virtual  machine  for  system 
software  development  eliminates  that  type  of  a  working  en- 
vironment. System  enhancement*  new  operating  system 
releases*  or  in  fact  any  software  development  can  be 
thoroughly  tested  and  debugged  on  the  virtual  machine  before 
being  released.  All  of  this  can  be  accomDlished  during  nor- 
mal working  hours  and  without  wasting  system  resources,. 

2 .  Elimination  Of  Certain  Conversion  Problems . 

This  benefit  was  earlier  examined  and  can  only  be 
truly  appreciated  when  one  has  lived  thro u ah  a  mass  conver- 
sion effort.  The  ability  to  be  selective  on  what  programs  to 
convert  and  not  to  be  rushed  in  that  conversion  is  alone  a 
great  advantage. 

3 «   Concur  rent  Punning  Of  Dissimilar  Dp  era  ting 
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This  application  would  be  extremly  useful  to  those 
data  orocessinq  installations  that  are  charged  with  the 
responsibility  of  developino  application  software  which  will 
be  distributed  to  many  installations  and  run  on  a  variety  of 
computer  sizes  and  models  and  under  different  operating 
systems.  In  fact/  copies  of  the  actual  operating  system  of 
the  individual  installation  in  which  the  program  will  be 
running  could  be  sent  to  the  testing  installation.  Then  the 
program  could  be  executed  on  a  virtual  machine  configured  to 
the  installation  and  tested  under  their  operating  system. 

Another  benefit  of  running  dissimilar  operating  systems 
is  computer  backup  capability.  If  an  installation's  comput- 
er went  'down  for  an  extended  period  of  time/-  the  installa- 
tion could  still  process  necessary  jobs  on  a  virtual ized 
system  using  their  backup  installation's  computer.  They 
could  use  their  own  operating  system  and  configuration 
thereby  avoiding  the  difficult  tasks  of  temporarily  modify- 
ing or  Generating  operating  systems  or  programs  generally 
required  when  one  has  to  move  their  processes  to  another 
comput  er, 

U  .   Test  i  nq  Future  Hardware, 

The  virtual  machine  gives  the  installation  the  anil- 
ity to  desianr  develop/  and  test  programs  that  will  b^  in- 
terfacing with  new  hardware  before  the  actual  hardware  is 
delivered.  In  addition  to  helping  in  the  program  develop- 
ment/ it  could  have  been  used  in  the  hardware  selection  pro- 
cess.  Different   types  and  models  of  hardware  devices  couli 
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hove    been    v-irtualized    and    tested    lor    their    applicability. 

b .       T  g s  t    Of    Network    F a  c  i 1 i  t ^  e  s . 

The  complicated  nature  of  test inq  and  implementing  a 
computer  network  would  be  greatly  simplified  if  many  of  the 
inter-communication  software  bugs  can  be  found  ar.ci  corrected 
on  the  system  before  the  actual  implementation. 

6.   Evaluation  Of  Program  behavior. 

The  nature  of  the  virtual  machine  monitor  lends 
itself  to  a  type  of  performance  monitoring.  Detailed  in- 
teractions between  the  software  and  machine  or  between 
software  modules  themselves  can  be  trapped?  measured?  and 
recorded  to  be  later  printed  cut  for  detailed  analysis. 
Changes  could  be  implemented  and  measured  again  to  check  the 
improvement  factor  before  making  the  real  modifications. 

7  .   Security  And  Privacy . 

The  virtual  computer  system  holds  great  promise  in 
the  area  of  security  and  Privacy.  As  mentioned  earlier?  it 
is  impossible  for  an  operating  system  to  tell  if  it  is  being 
executed  on  the  real  or  virtual  machine.  Each  machine  vir- 
tual is  completely  isolated  from  each  other  so  it  would  be 
impossible  to  spy  on  or  try  to  alter  any  coexisting  machine. 

8.   Education. 

The  ability  for  a  student  in  the  computer  science 
field  to  be  able  to  have  his  own  computer  and  operating  sys- 
tem is  a  blessing  to  both  student  and  computer  center 
manager.  Here  he  can  w  o  r  K  with  and  alter  on  his  own  an 
operatinq  s y s t e m *  without  the  under! vinq  fear  of  destroying 
the   real   system?   for   the   only   way  to  truly  learn  about 
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operating  systems  is  to  actually  perform  system   maintenance 
on  a  real  system. 
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III.  *KCH1TECTUF<AL  DESIGN  OF  THE  PDP-11/50 


This  chapter  is  primarily  designed  to  hiqhliqht  onl v 
certain  areas  of  the  architectual  design  of  the  PDP-J1  rami- 
1 y  of  computers.  Attention  is  mainly  given  to  c  c  m  o  u  t  e  r 
design  characteristics  which  relates  to  virtual ization  prob- 
lems. It  is  not  intended  as  a  ccnoiete  or  detailed  analysis 
of  the  internal  comouter  workings.  The  interested  reader 
will  find  a  complete  and  detailed  description  in  references 
[7]  and  [8]  . 

The  PDP-11/50  is  a  general  purpose*  interrupt  driven, 
three  state  computer,  capable  of  directly  addressing  23 '< 
sixteen  bit  words  of  memory  without  the  memory  management 
unitr  and  1  ?  4  k  words  with  memory  management.  It  contains  two 
independent  sets  of  six  general  purpose  reqisters,three 
stack  pointer  registers  (one  SP  for  each  state),  and  a  pro" 
gram  counter  register  (PC). 

The  PDP-11/50  in  addition  to  the  optional  memory  manage- 
ment unit,  supports  an  optional  floating  point  processor, 
ana  a  host  of  peripheral  devices.  The  system  is  designed  to 
support  a  virtual  memory  multiprogramming  environment.  The 
basic  relationship  of  these  different  units  are  d  e  D  i  c  t  e  d  in 
figure  8 . 

The  general  puroose  registers  are  rather  unique  in  that 
I/O  operations  do  not  di^turo  their  contents  and  secondly, 
they  can  be  used  in  a  diversity  of  register  operation^,, 
namelv  as  accumulators,  index  registers,  stack  pointers, 
autoincrement  and  autodecrement  registers. 
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The  instruction  set  is  probably  the  most  powerful  asset 
of  the  PDP-11/50  computer.  The  instruction  set  consists  of 
over  four  hundred  microproqrammed  instructions.  Instruc- 
tions are  so  flexible  that  a  proqrammer  has  numerous  options 
available  for  codinq  any  Program  routine. 

The  architectural  design  feature  of  the  PDD-11  family 
of  computers  that  distinguishes  it  from  other  DEC  systems  as 
well  as  from  other  computer  vendors  is  the  UN  IB US.  The 
UNIBUS  is  a  high  speed  (five  million  bytes/seconds), 
asychronousr  bidirectional  channel  that  ties  all  system  com- 
ponents together  (figure  9). 

All  memory  and  processors  are  connected  to  the  UNIBUS  in 
a  regular  manner.  The  same  addressing  scheme  is  applied 
egually  well  to  a  specific  device*  memory  or  processor.  This 
greatly  simplifies  I/O  programming  because  the  entire  in- 
struction set  is  available  for  inout/output  routines. 

Machine  instructions  that  effect  the  UNIBUS  operation 
or  devices  attached  to  the  UNIBUS  would  qualify  as  sensitive 
instructions. 

The  PDP-11/50  is  a  three  state  machine*  as  compared  with 
the  conventional  two  state  (supervisor  and  program)  opera- 
tion. The  three  states  or  modes  are  kernel/  supervisor;  and 
user.  Kernel  mode  programs  are  unrestricted  in  their  use  of 
the  machine  while  the  programs  operating  in  the  user  and 
supervisor  modes  are  restricted  in  the  kind  and  number  of 
instructions  which  tiay  be  legally  executed.  The  supervisor 
mooe  is  only  slightly  more  Powerful  than  the  user  mode. 

It  is  interesting  to  note  some  instructions   (RtSET/SPLc 
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etc*)  are  ionorea  if  not  in  the  kernel  mode  while  other 
instructions  (HALT)  generate  an  interrupt.  This  inconsis- 
tency* esoecially  when  encountered  in  the  sensitive  instruc- 
tion set*  adds  to  the  comolexity  of  virtual i zing  the  PDP-11 
family  of  comouters. 

The  processor  status  word  (PS)  is  a  special  memory  cell 
located  in  the  upper  4k  of  the  machine's  memory.  (The  upper 
4k  is  not  actual  memory  but  addresses  of  device  registers 
located  on  the  device.)  The  current  machine  operation  mode 
at  any  given  instance  is  completely  determined  bv  the 
current  mode  bits  in  the  PS. 

The  PS  may  be  changed  in  one  of  three  ways:  (1)  Explici- 
tVf  by  physically  modifing  it  via  a  normal  machine  instruc- 
tion such  "as  MOV.  (?)  Implicitly*  through  the  use  of  one  of 
the  several  machine  instructions  such  as  SPLrRTTrRTI  which 
cause  the  PS  to  be  implicit/  changed*  and  (3)  Asynchronous- 
ly* as  a  result  of  an  interrupt  or  trap. 

The  ability  to  explicitly  modify  the  PS  and  in  fact  to 
do  any  actual  I/O  is  a  function  of  whether  or  not  the 
program's  virtual  a d dress  soace  is  mapped  into  that  portion 
of  the  machine's  physical  memory  which  contains  the  PS  and 
device  registers.  Programs  operating  in  the  user  or  super- 
visor mode  are  generally  restricted  in  this  manner  causina 
for  example*  I/O  to  be  initiated  only  from  the  kernel  it- 
self. Figure  !0  illustrates  the  real  and  virtual  memory  map. 

Instructions  caoable  of  modifying  the  PS  (SPL * R T I  * RTT ) 
also  qualify  as  sensitive  instructions.  This  would  include 
a  MOV  instruction  if  allowed  to  access  the  I/O  page. 
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The  I/O  structure  of  the  PDP-11/50  is  one  of  the  true 
advantaqes  ouilt  into  the  system's  architecture  and  can  he 
one  of  the  biaaest  disadvantages  in  virturalizing  the  sys- 
t  em  r  depending  on  how  the  uoper  4  k  of  virtual  memory  is 
mapped  into  physical  address  space. 

It  would  be  highly  advantageous  if  the  upoer  4k  virtual 
addresses  of  a  program  executing  on  the  virtual  machine  were 
allowed  to  m  a  o  directly  into  the  physical  I/O  page*  and  the 
access  control  field  of  the  page  description  reoister  is  set 
to  abort  all  accesses.  Thus  this  type  of  sensitive  instruc- 
tion is  coriviently  traoped.  If  this  is  not  the  case  then 
because  of  the  flexibility  of  the  instruction  set  and  espe- 
cially if  the  program  has  no  restrictions  on  the  method  of 
accessing  "the  I/O  paqef  then  one  is  lead  to  a  one  hundred 
percent  instruction  interrogation  and  a  large  increase  in 
instruction  simulation  routines. 

The  design  considerations  for  the  asychronous  interac- 
tion oetween  modes  is  based  around  stack  operations.  A  stack 
is  a  temporay  storage  area  (one  for  each  mode)  used  in 
subroutine  and  interrupt  service  linkage. 

Individual  program  stacks  can  be  directed  to  start  at 
any  virtual  address  and  can  expand  either  upward  or  down- 
ward. Any  register  can  serve  as  a  stack  pointer.  The  main 
register  used  bv  the  system  for  this  function  is  the  stack 
pointer  register  (SP),  which  by  design  expands  downward.  As 
ealier  mentioned/  there  is  a  separate  SP  for  each  mode. 

Interrupts  and  subroutine  linkage  are  very  similiar  end 
only  differ  in  their  method  of  invocation  and  the   reoisters 


that  are  stacked  and  loaded.  Interrupts  are  forced  while 
subroutine  linkage  is  controlled  oroqram  transfer.  In  addi- 
tion, subroutine  linkage  only  effects  the  PC  and  not  the  PS. 
The  action  is  basically  as  follows:  The  old  PS  (if  cause d 
by  an  interrupt)  and  the  current  ^C  are  automatically 
stacked  onto  the  new  processor  stack  and  the  new  linkage 
information  (PS  if  required  and  PC)  are  placed  in  the  regis- 
ters. 

All  interrupts  are  required  to  be  simulated  under  a 
virtural  machine,  subroutine  calls  are    not. 

This  brief  examination  of  the  PDP-11/50  architecture 
clearly  illustrates  that  the  PDP-li/50  was  not  designed  for 
supporting  a  vitural  machine  application.  In  fact,  without 
significant  hardware  modifications  a  true  virtural  comouter 
system  can  not  realized. 
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IV.  PROBLEM  DEFINITION  AM)  POSSIBLE  APPROACHES 

The  current  st^tP-of-t^e-art  of  computer*  science  offers 
a  variety  of  approaches  that  may  be  employed  to  virtualize  a 
comouter  system.  Virtual ization  methods  can  range  from 
extremely  expensive  and  complicated  hardware  modifications 
to  that  of  only  minor  systems  changes  to  suoport  a  limited 
type  II  virtual  machine  monitor. 

The  first  step  in  determining  the  type  of  virtual ization 
approach  to  use  is  to  examine  the  computer  manager's  plans 
and  goals  for  the  installation.  Management's  desires  will 
automatically  eliminate  many  of  trie  possible  approaches. 
Therefore/  a  brief  examination  of  the  Naval  Postgraduate 
School's  PDP-11/50  computer  to  include  the  computer's  en- 
vironments primary  user  and  the  general  goals  of  the  school 
towards  the  computer  system  is  in  order,  "I'his  examination 
will  highlight  the.  imposed  restrictions  on  virtual! zing  the 
syst  em. 

A.   SYSTEM  ENVIRONMENT 


The  Naval  Postgraduate  School  has  two  PDP— 1 1/SO  comput- 
ers and  a  wealth  of  periohial  devices.  T h e s p  computers  are 
not  intended  to  serve  the  school  in  a  computer  service 
bureau  fashion/  but  are  incoroorted  into  a  computer  research 
laboratory. 

The  primary  research  areas  of  this  computer  laboratory 
are  in  the  fields  of  operating  systems  design  and  r e  s  e  a  r c h ? 
signal  p  r  o  c  e  s  s  i  n  g ,     computer  graphics*  snci    hybrid  computing. 
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Temporary  configuration  modifications  for  a  Specific 
research  project  offer  no  real  problems.  Peripherials  con 
be  switched  between  computers  in  matters  of  minutes  tc  meet 
any  new  demands.  This  versitility  is  mainly  do  to  the  stan- 
dard interface  of  the  UN  I  BUS. 

Managements  qoals  though/  are  to  have  all  I/O  devices 
ana  computers  tied  toaether  to  support  a  real  timer  mul- 
tiprogramming, multiprocessing  operating  environment.  The 
general  conf iourat ion  envisioned  is  schematically  illustrat- 
ed in  apnendix  (B).  It  is  a  general  configuration,  since  the 
wide  range  of  activities  ,  will  continually  demanding  confi- 
guration modifications, 

A  greatly  enchanced  version  of  the  UNIX  ooerating  system 
(called  M  (j  N I  X  )  is  being  designed  as  the  primary  operating 
system  to  support  the  desired  system  environment. 

UNIX  itself  is  a  general  purpose,  multiuser,  interactive 
operating  system  developed  at  dell  Laboratories.  UNIX  con- 
tains a  number  of  sophisticated  features  generally  only 
found  on  large  systems,  but  with  the  surprising  and  unusual 
guality  of  simplicity  and  ease  of  use.  &  complete  and  excel- 
lent abstract  of  UNIX  is  contained  in  reference  ?.B . 

Even  though  UNIX  is  extremely  powerful  and  versatile  it 
would  not  meet  the  complete  demands  that  would  be  reguired 
of  the  operatinq  system.  MUNIX  is  being  developed  to  meet 
those  addition  demands  of  real-time  processing, 

B.   VIRTUAL  I Z AT  ION  GOALS  AND  PROBLEM  AREAS 


n  6 


The  Naval  Postgraduate  School *9  desired  goal  in  the  area 
of  visualization  of  the  PDP-11/50  can  be  summarized  as  f  o  1  - 
1  ows  : 

1  •  Achieve  the  capability  to  produce  a  virtu- 
al ized  PDP-11/50  computer  that  would  support  all 
available  operating  systems  and  be  able  to  access 
any  real  or  virtualized  I/O  device. 

2 .  The  virtual  machine's  efficiency  would  be 
sufficient  to  reasonably  execute  most  types  of 
appl ications. 

3.  Incoroorate  a  complete  debugging  aid  fa- 
cility to  assist  the  user  in  executing  and  pro* 
gramming  on  the  virtual  machine. 

The  decision  was  made  that  any  implementation  of  a  vir- 
tual system  would  be  reoui  red  to  operate  under  the  M  U  N I  X 
system.  This  thereby  eliminates  any  tyoe  I  virtual  machine 
monitor  considerations. 

A  futher  decision  and  restriction  was  that  the  virtual 
machine  monitor  olus  programs  executing  on  the  virtual 
machine  would  execute  in  the  user  mode  arid  in  a  similar 
manner  to  any  other  process. 

This  restriction  imnosed  a  serious  problem  on  referenc- 
ing the  I/O  page.  Since  the  I/O  nagc  comprises  the  upper  '4k 
of  the  address  soace>  all  programs  on  the  virtual  machine 
would  reference  this  space  for  testing  and  excuting  I/O. 
MUNIX*   on   the   other  hand?  uses  this  virtual  address  space 
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for  the  user  stack  area.  This  restriction  also  imposes  the 
problem  of  having  two  user  mode  processes  executing  con- 
currently and  in  harmony  but  at  the  same  time  having  one  of 
the  processes  (virtual  machine  monitor)  be  the  supervisor. 
It  was  also  decided  that  the  visualization  design  would  if 
at  all  possible*  minimize  modifications  to  the  operating 
system. 

The  main  problem  areas  identified  in  both  the  hardware 
architecture  and  software  restrictions  can  now  be  sum mar- 
i  ?ed. 

1.  That  a  true  virtual  system  cannot  be  in- 
corporated on  the  PDP-11/50  as  defined  by 
Goldberg's  Theorem  1*  since  all  identified  sensi- 
tive instructions  (apoendix  C)  are  not  a  subset  of 
the  privileged  instructions. 

?..,  That  the  identified  sensitive  instructions 
vary  in  their  method  of  execution  when  encountered 
in  the  user  mode.  For  example*  the  HALT  causes  a 
trap*  a  R  E  S  E  T  causes  a  "no  op*  and  a  R  T  I  is  executed 
in  a  normal  manner*  i.e.  independent  of  mode. 

3.  That  the  I/O  page  accessing  the  user  pro- 
gram and  the  M  U  N  I  X  user's  space  area  are  incompat- 
abl  e. 


4.  That  the  virtual  machine  monitor  should  be 
c  o  m  p 1 e  t  e 1 y  separate  from  the  job  executing  on  the 
virtual   machine*   i.^.  not  in  the  same  addressing 
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spacer  but  at  the  same  time  have  the  ability  to 
access  and  examine  in  detail  the  processes'  regis" 
t  e  r  s  *  PS*  and  memory.  The  virtual  machine  monitor 
must  also  have  the  capability  of  controlling  the 
program^  execution. 

C.   MILESTONES 

The  acheivement  and  success  of  the  desire d  goals  re- 
quires a  great  amount  of  complex  design*  coding,  and  process 
interaction.  This  is  especially  true  if  the  time  span  re- 
quired to  attain  these  goals  incluoes  a  series  of  program- 
ming teams.  A  methodical  plan  must  first  be  initiated  and 
implemented  in  order  to  have  the  end  product  useable  and 
efficient.  Each  hierarchical  step  of  the  plan  must  be  logi- 
cally dsvelooedf  flexible*  and  modular  for  good  program  con- 
trol and  documentation.  The  following  outlines  the  essen- 
tial milestones  to  meet  the  objectives  of  a  truly  virtual- 
ized  PDP-1 1/SO. 


STEP  1  -  Develop  the  basic  foundation  and 
necessary  tools  to  suooort  a  limited  virtual 
machine.  The  virtual  machine  would  execute  stand- 
alone processes  subject  to  the  following  restric- 
tions. First*  interrupt  handling  would  not  be 
included.  Secondly*  methods  of  accessing  the  I/O 
page  would  be  restricted.  Finally*  only  those  sen- 
sitive instructions  that  are  required  for  basic 
programming  be  simulated. 
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STEP  ?  -  Develon  and  incorporate  a  complete 
interruot  handling  process. 

STEP  3  -  Complete  the  simulation  of  all  sensi- 
tive instructions. 

STEP  1  -  Develop  and  include  an  efficient  but 
unlimited  I/O  capability.  The  consolidated  virtual 
machine  monitor  would  now  have  the  ability  for 
supoortino  a  virtual  machine  that  could  process 
any  stand-alone  job. 

STEP  5  -  Complete  the  final  enchancements  of 
having  the  virtual  machine  capable  of  supporting 
different  onerating  systems. 

Examination  of  several  visualization  projects  at  other 
institutions/  in  the  area  of  man-hour  development  of  a  pro" 
ject  of  this  size/  estimates  this  effort  to  be  approximately 
one  to  two  years  depending  on  the  implementation  method. 
Our  goal  is  to  comolete  the  first  milestone/  putting  em- 
phasis on  developing  the  tools/  plus  program  modularity  for 
ease  of  future  enchancements. 


D.   POSSIBLE  APPROACHES 

To  meet  the  reguired  visualization  objectives  of  the 
school/  four  possible  approaches  were  examined.  The  ap- 
proaches varied  considerably  in  cost/  sophisication/  and 
implementation  ease.  Tne  approaches  were: 
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1 .  Acquire  if  possible/  virtual  machine  moni- 
tor software  already  developed  for  the  PDP-11  com- 
puter family  from  anotner  institution  or  source. 
This  aDnroach  is  the  most  logical  and  has  the 
greatest  appeal  in  firstc  not  'reinventing  the 
wheel',  and  secondly,  snending  the  majority  pro~ 
gramming  effort  on  converting  and  adapting  it  to 
our  env  i  ronment  . 

2 .  Acquire  and  implement  necessary  hardware 
modifications  to  the  PDP-11  system  so  as  to  im- 
prove its  virtual izable  characteristics.  A  true 
and  efficient  virtual  system  can  never  be  realized 
on  a  PDP-11  comnuter  until  the  execution  of  all 
sensitive  instructions  in  the  user  mode  automati- 
cally interrupt  the  system's  processing.  This  type 
of  modification  of  the  hardware  though,  may  lead 
to  many  undesirable  side  effects.  For  example, 
vendor  maintenance  aareements  may  be  endangered, 
plus  the  real  possibility  of  degradation  of  normal 
processing. 


3.  All  proarams  to  be  executed  on  the  virtual 
machine  would  first  be  examined  by  a  preprocessor. 
The  function  of  the  preprocessor  would  be  to  iden- 
tify and  substitute  a  processor  trap  instruction 
for  all  sensitive  instructions  encountered. 

This  aporoach  has  the  advantages  of  being  the 
most   cost   sensitive   and   relatively    easy    to 
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implement  but  has  three  main  disadvantages,  Firsts 
the  time  spend  for  pr eorocess i ngj  secondly;  the 
ease  of  anyone  intentionally  or  unintentionally 
beatina  the  preorocessor  since  data  and  instruc* 
tions  are  interspersed  in  a  program  and  confusion 
between  the  two  are  easily  made;  finally/  and  most 
important/  the  inability  of  processinq  a  program 
which  contains  self-modifying  code.  This  includes 
many  operating  systems. 

4.  Implement  some  extensive  operating  system 
modifications  to  ease  the  visualization  effort. 

Although  this  approach  is  in  variance  with  the 
restriction  on  minimizing  operating  system  modifi- 
cations/ some  of  the  major  problems  could  be 
resolved.  For  instance/  it  woulo  be  highly  desire- 
able  to  have  the  I/O  paqe  available  to  the  virtual 
processes  thus  solving  the  I/O  problem  and  either 
eliminate  or  relocate  the  user  stacks.  This  would 
reguire  the  operating  system  to  distinguish  a  real 
from  a  virtual  process  for  appropriate  stack  han- 
dling and  memory  mapping.. 

Another  very  appeal i  n  g  imolementation  method 
is  to  have  the  virtual  machine  monitor  execute  in 
the  supervisor  mode  while  the  virtual  processes 
run  in  the  user  mode.  This  would  solve  the 
memory  address  space  Problem  and  have  the  virtual 
monitor  anove  the  user  but  less  then  the  operating 
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system.  This  also  would  require  extensive  modifi- 
cations since*  M  U  M  I  X  only  uses  the  kernel  and  user 
mode. 

There  are  always  considerable  techinical  problems  in 
modifying  any  operating  system.  This  is  especially  true  at 
the  present  time  of  the  UNIX  system.  It  is  first*  relatively 
new  to  all  oersonnel  at  the  school/  including  the  C-lanquage 
which  it  is  written  in,  but  more  important  the  operating 
system  is  almost  completely  undocumented.  The  majority  of 
effort  to  date  has  been  in  learning,  documenting,  and  modi" 
fying  the  more  important  areas  of  the  system. 
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V.   SELECTION  AND  IMPLEMENTATION 


A.   SELECTION 


The  preprocessor  approach  was  selected  as  the  method  for 
virtual izing  the  PDP-11/50.  Although  this  method  has  some 
substantial  disadvantages  as  outlined  in  chapter  IV*  the 
cost*  ease  of  implementation*  and  time  limitations  more  than 
compensated  for  them.  This  method  also  assisted  in  overcom- 
ing some  of  the  conflicts  and  undesireable  effects  of  run- 
ning under  MUNIX  and  without  making  any  modifications  to  the 
MUNIX  system. 

The  search  for  existing  virtual  machine  monitor 
software^  for  the  PDP-ll/50r  identified  only  one  other  edu- 
cational institution  involved  in  this  area .  The  University 
of  California*  at  Los  Angeles?  under  the  direction  of  Pro- 
fessor Gerald  J.  Ponek  is  currently  involved  in  virtual izing 
a  PDP-11/45  computer.  One  of  their  main  research  efforts  to 
date  has  been  in  the  area  of  computer  security  and  the  vir- 
tual machine.  Their  implementation  method  involves  a  type  I 
virtual  machine  monitor  plus  an  additional  nlugeble  hardware 
modification  module*  (the  Virtual  Machine  Extension 
KBS11-A),  desioned  and  manufactured  for  them  by  Digital 
Eguioment  Coporation  (DEC).  The  hardware  module  simply  plugs 
into  the  system  when  the  virtual  machine  monitor  is  running 
and  efficiently  traos  all  sensitive  instructions. 

Professor  Ponek  was  contacted  for  the  possibility  of 
usinq  any  of  their  software  modules  in  our   virtual   machine 
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monitor.   It  was  decided  that  at  this  time*  it  would  be  very 

impractical  since  their  virtual   monitor   is   still   in   the 

development   staqe»   written   in   a   different  language*  and 

mostly  undocumented.  Professor  Popek  did   recommend   thouah/ 

that   we   purchase   from   DEC   the  hardware  'virtual  machine 

extension'.   The  virtual  machine  extensions  option  (KBS11-A) 

is  an  available  Digital  Equipment  Corporation  option  for  the 

PDP-11/45  and  PDP~ll/50  computers  at  a  cost  of   $5995.    Its 

specific   function   is   to  facilitate  the  writing  of  virtual 

machine  monitor  code. 

The  K B S 1 1 - A  provides  the  following  features:  [10] 

" 1 .  It  provides  the  ability  to  trap  certain  "con- 
trol- sensitive"  instructions  when  they  are  en- 
countered in  user  and/or  supervisor  mode.  These 
instruction sr  characterized  by  the  fact  that  they 
ooerate  differently  in  user  or  supervisor  mode 
than  in  kernel  mode/  are: 

HALT  -  dalt  Instruction  Execution 

WAIT  -  Wait  for  Interrupt 

RESET  -  Reset  the  system 

RTI  -  Return  form  Interrupt 

RTT  -  Return  from  Trap 

SPL  -  Set  Priority  Level 

MTPI   -   Move   to   Previous   Instruction 

Soace 

MTPD  -  Move  to  Previous  Data  Space 

MFPI   -   Move   from  Previous  Instruction 

Soace 

MFPD  -  Move  from  Previous  Data  Space 
In  the  virtual  machine  environment/  these  instruc- 
tions must  be  trapoed  and  then  simulated  by  the 
operating  software.  To  aid  in  the  servicing  of 
these  instructions*  the  KRS11-A  hardware  encodes 
each  of  these  instructions  into  a  unique  4 -bit 
number  which  can  be  read  by  the  service  routine. 
This  eliminates  software  decoding  of  the  instruc- 
tions. The  snecified  instructions  cause  a  reserved 
instruction  trao/  vector  10. 

2.  It  orovides  the  ability  to  set  up  an  al- 
ternate vectc  space  to  be  used  for  traos  and 
interrupts  f rem  user  mode.  The  effect  is  to 
"offset"/  by  1000/  2000/  or  3000  (octal)/  any  vec- 
tor*  address   generated   while  the  processor  is  in 
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user  mode.  This  is  done  so  that  a  supervisor  pro- 
gram can  service  certain  trans  from  user  programs 
directly  while  still  allowing  the  Kernel  mode  pro" 
gram  full  control  of  the  system  (all  vectors  are 
in  Kernel  address  soace). 

3.  It  provides  a  User  Stack  Limit  Register* 
similar  in  operation  to  the  Kernel  Stack  Limit 
Register.  without  this  capability?  the  only  other 
way  of  limiting  the  user  stack  is  by  means  of  the 
Memory  Manaoement  unit,  t  which  limits  virtual 
machine  structure  and  flexibility." 


The  KBS11-A  option  contains  no  operator  controls/  but  is 
under  full  orogram  control  by  means  of  three  registers  on 
the  UNIBUS.   The  three  registers  are  the  following: 

1.  VCSR  VMX  Control -Status   Register   -   This 

( 
register   contains  seven  control  bits  to  enable  or 

disable  the  various  extended  processor  features* 

2.  VCODE  VMX  Reserved  Instruction  Cede  Regis" 
ter  -  This  reoister  contains  a  four  bit  code  for 
easy  identification  of  the  instruction  that  caused 
t  he  t  rao. 

3.  VUSL  VMX  User  Stack  Limit  Register  -  This 
register  contains  the  user  stack  limit  address 
which  operates  like  the  standard  kernel  mode  stack 
limit  regi  ster, 


When  the  KBS11-A  is  disabled,  the  KBSli-A  hardware  has 
no  effect  and  the  processor  operates  as  normal.  This 
hardware  ootion  solves  all  of  the  hardware  problems  and 
lends  itself  for  creating  a  true  virtual  machine.  The  cost 
of   the   K  B  S  1  1  *■  A   is   currently  the  prohibitive  feature*  but 
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until  this  hardware  option  or  one  similar  to  it  is  installed 
the  aoals  of  the  school  toward  visualization  will  never  be 
at  tended. 

B.   DFSIGN  CONSIDERATIONS 

With  the  objective  of  implementing  a  basic  virtualized 
PDP-11/50  computer  (chapter  IV  -  first  milestone)*  the  fol- 
lowing design  characteristics  and  considerations  were  adopt- 
ed. 

1.  The  virtual  machine's  configuration  will 
consist  of  one  PDP-11/50  computer'  without  a  memory 
management  unit*  32k  words  of  memory  r  and  one  LA30 
DEXwriter  termininal. 


2.  Job  processing  will  be  restricted  to  stan- 
dalone jobs  that  have  been  oreprocessed  for  sensi- 
tive instruction  substitution.  Jobs  also  will  be 
restricted  in  the  method  of  accessing  I/O  arid  in 
not  using  interrupt  type  processing.  The  'MOV 
instruction  employing  direct  indexing  will  be  the 
only  instruction  allowed  to  reference  the  I/O  page 
and  the  'HALT'  instruction  will  be  used  for  exit- 
ing from  the  user  program. 

3.  The  debugging  aid  will  include  the  follow- 
ing capabilities:  (1)  Be  able  to  display  the  con- 
tents of  the  general  registers?  program  status 
word  and  memory.   Memory   may   be   displayed   both 
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o  c  t  a  1 1 y  and  symbolically;  (?)  Be  able  to  modify 
any  register  or  memory  cell?  (3)  Provide  the  abil- 
ity for  breakpoint  processing. 

4 .  The  program  will  be  written  in  the  C - 
language/  be  modular  in  design  for  ease  of  incor- 
porating enhancements  and  unders t and i nq,  and  in- 
corporate a  built  in  internal  debugger  that  will 
upon  command,  give  the  value  of  the  variables 
encountered  throughout  the  program. 

C.   IMPLEMENTATION 


1.   Program  Overview 

The  virtual  machine  monitor  consists  of  the  follow- 
ing functional  units.  (Figure  11  illustrates  these  function- 
al units  and  their  relationships). 

a.  Supervisor  Monitor 

The  supervisor  monitor  is  the  highest  level 
module  of  the  virtual  monitor.  It  provides  the  main  communi- 
cation between  user  and  virtual  machine.  It  acceots  and 
edits  the  virtual  machine  monitor  commands  and  calls  and 
supervises  their  execution. 

b.  Preprocessing  Monitor 

The  preDrocess i ng  monitor  edits*  calls,  and  mon- 
itors the  preorocessor  executions. 
c •   Preorocesso  r 

The  preprocessor  is  a  completely  self-contained 
module   that   examines   incoming   virtual   machine   job   for 
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S  e  n  s  t  v  t  v  v  e  instructions  and  o ossicle  substitution.  Its  out- 
put is  a  modified  executable  (a. out)  f  i  j  e  and  a  sensitive 
instruction  table. 

d.   Execution  Monitor 

The  execution  monitor's  function  is  to  start  or 
continue  the  executing  of  the  job  on  the  virtual  machine.  I  v 
a  breakpoint  or  sensitive  trap  is  encountered  in  the  program 
the  execution  monitor  receives  the  interrupt  and  calls  the 
dispatcher  for-  servicing. 

e  .   0  i  spat cher 

The  dispatcher  determines  the  type  of  problem 
encountered  in  the  orogram  and  calls  (if  necessary)  the 
reguired  sensitive  instruction  simulator  or  breakpoint 
handl e  r . 

f.  Sensitive  Instruction  Simulators 

These  routines  (one  for  each  sensitive  instruc" 
tion)  simulate  the  execution  of  the  individual  sensitive 
instructions. 

g.  Debug  Modu 1 es 

The  debug  modules  are  available  to  the  general 
user  for  assistance  in  program  debugging  and  in  examining 
program  execution. 

ha   Internal  Program  Debugger 

When  this  is  activated;  variable  values  used 
throughout  the  orogram  are  displayed  to  aid  in  o e bugging , 
This  function  is  not  intended  for  the  general  user  but  in- 
stead for  the  virtual  machine's  monitor  maintenance*  debug - 
ging*  and  enchancement  verification, 
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i  .   M  i  s  c  e  H  a  n  e  o  u  s  Utility  Functions 

This  is  a  general  collection   of   utility   func- 
tions used  b  v  the  main  modules. 
2.   Supervisor  Monitor 

The  supervisor  monitor  (named  '  *■  v  m  m  ' )  is  a  small 
simple  routine  which  controls  and  directs  the  main  flow  of 
the  program,  as  directed  by  the  user's  commands.  It  is  the 
highest  level  module  of  the  virtual  machine  monitor  and  the 
one  that  is  entered  when  the  monitor  program  is  executec. 
Its  action  is  simnly  to  wait  for  a  user  command,  edit  the 
command,  and  initiate  a  call  to  the  correct  module  for  pro- 
cessing. After  the  called  process  has  completed*  control  is 
returned  to  the  supervisor  monitor.  The  supervisor  monitor 
then  waits  for  the  next  command. 

The  following  is  a  list  of  the  valid  commands  and 
their  respective  functions. 

COMMAND  FUNCTION 


p  f  i 1  ex  [y/n]   [b] 


Preprocess  filex.  This  com- 
mand has  two  optional  parame- 
ters. The  first  indicates 
whether  the  user  wants  to  be 
informed  when  a  sensitive 
instruction  is  encountered. 
The  second  activates  the 
preprocessor's  internal  de- 
bugger. 


Start    or    continue   program 
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execution. 


b   ADDR 


Put   a   breakpoint   at  address 
ADDR 


d   r 


d   o   ADDR  U 


Display  all  general  registers 
plus  the  program  status  word. 

Display  memory  in  octal  start- 
ing from  address  ADDR  for  # 
number  of  words. 


d   s   ADDR   # 


m   rX   VALUE 


Display  the  program  symboli- 
cally from  address  ADDR  for  U 
number  of  instructions. 

Modify  register  X  to  VALUE, 
(octal ) 


m   SP   VALUF 


Modify   stack  pointer  to  VALUE 
(octal ) . 


m   PC   ADDR 


Modify   the  proaram  counter  to 
address  ADDR. 


m   PS   VALUE 


Modify  the  program  status  won 
to  VALUE  (octal ) . 


m   mem   ADDR   VALUE 


Modify   memory  at  address  ADDR 
to  VALUE  (octal ) . 


Enter  internal  debug. 


b? 


x  Leave  internal  debug. 

s  Terminate  the  execution  of  the 

virtual  machine  monitor. 

3 .   Preoroc  essor 

The  preorocessor  orogram  (named  '«-vmm001')  is  a  self 
contained  module  whose  function  is  normally  required  only 
once  for  each  job  processed  on  the  virtual  machine.  Because 
of  its  infrequent  user  the  preprocessor  is  loaded  into 
memory  and  executed  only  when  needed.  The  preprocessor  is 
called  by  the  preprocessing  monitor.  The  interaction 
between  the  Dreprocessing  monitor  and  the  preprocessor  pro- 
gram is  coordinated  by  a  series  of  M U N I X  system  calls  as 
i VI  us t rated  in  fiqurp  1?  . 

The  input  to  the  preprocessor  is  programs  which  are 
to  be  executed  on  the  virtual  machine.  These  programs  must 
be  in  the  form  of  an  executable  (a. out)  file  with  non- 
sharable  segments.  The  user  program  input  is  read  into  the 
preprocessor  in  blocks  of  b\?  bytes  for  improved  effeciency. 
The  preprocessor  program  examines  end  tests  each  program 
instruction  in  the  text  seqment  for  sensitivity.  If  such  an 
instruction  is  found  the  'TRAP'  instruction  (104450)  re- 
places it  and  the  sensitive  instruction  is  then  written  in 
the  sensitive  instruction  table. 

The  preprocessor  program  has  three  arguments.  The 
first  argument  is  mandatory  and  gives  the  name  of  the  pro- 
gram (a. cut  file)  for  preprocessing.   The  second  argument  is 


63 


INTERACTION  BETWEEN  PREPROCESSING  MONITOR  AND  PREPROCESSOR 

PREPROCESSING  MONITOR 
EXECUTION 


FORK  (  ) 


A  new  system  process  is  created 
by  copying  the  core  image  of  the 
caller  of  fork.  The  new  process 
is  the  child  of  the  old  process 
the  parent 


PARENT  (old  process) 


WAIT  (  ) 

Causes  the  parent  to 
to  delay  execution 
until  the  child 
process  has 
terminated. 


Continues 
execute 


to 


CHILD  (new  process) 


EXEC  (-VMP001) 

Program  -VMP001  overlays 
child  and  starts  execution 
at  the  beginning  of  the 
program.  There  is  no 
return  to  the  original 
child  process. 


-VMP001  starts 
execution 


-VMP001  terminates 
(activates  parent) 


FIGURE  12 


64 


optional  allowing  the  user  a  choice  of  whether  he  wants  to 
be  notified  when  a  sensitive  instruction  is  encountered. 
(Default  value  is  'do  not  notify').  rthen  notification  is 
desired*   the   sensitive   instruction  plus  the  five  previous 

• 

instructions  of  the  program  and  their  location  are 
displayed.  It  is  at  this  time  that  the  user  can  exercise  the 
option  of  agreeing  or  disagreeing.  If  the  user  agrees*  the 
'TRAP'  instruction  will  be  substituted*  otherwise  no  substi- 
tution will  be  made.  It  must  be  emphasized  that  in  the  no™ 
tificetion  mode*  the  user  decides  if  a  sensitive  instruction 
has  been  encountered.  The  final  optional  argument  is  the 
internal  debug  switch  for  the  preprocessor  (Default  value 
'is  no  debug ' ) . 

The-  'JSP'  and  'TRAP'  instructions  have  the  possibil- 
ity of  having  a  variable  number  of  parameters  following  them 
(these  parameters  freouently  look  like  'JSR'  or  'TRAP'  in- 
structions to  the  preprocessor).    Because   of   this   unique 

* 
characteristic*  the  preprocessor  will  automatically  printout 

the  five  previous  instructions*  the  sensitive  instruction 
encountered*  and  a  message  reguesting  the  number  of  parame- 
ters that  are  following  the  instruction.  The  user  can  then 
indicate  to  the  oreprocessor  the  number  of  parameters  to 
skip. 

The  oreprocessor's  output  is  a  modified  a, out  f  i  1  ^ 
(named  «-  v  m  m  0  0  <?  )  void  of  all  sensitive  instructions  and  a 
sensitive  instruction  table  (nameo  <-vmm003)  containing  the 
encountered  sensitive  instructions  and  their  addresses. 

The  program  logic  flow  is  illustrated  in  figure  15. 
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4  .   Execution  Monitor 

The  execution  monitor  controls  the  starting  and  res- 
tarting of  orocesses  executinq  on  the  virtual  machine.  AM 
processes  running  under  M  U  N  I  X  have  two  executable  forms. 
The  first  form  is  the  a. out  file  for  programs  ready  to  be 
executed.  The  second  form  is  the  core  image  file  used  during 
execution  (f inure  14).  The  virtual  machine  monitor  frequent- 
ly accesses  one  or  both  of  them  (depending  on  if  the  process 
has  been  initially  executed).  During  the  course  of  program 
execution  these  two  files  differ  in  location.  The  a. out 
file  is  located  in  the  user's  library  while  the  core  image 
file  is/  when  not  executing/  located  in  the  system's  swap 
area. 

If  the  process  has  never  been  executed/  the  execu- 
tion monitor  initiates  the  process'  execution  in  the  same 
manner  (fork/  exec)  as  the  Preprocessor  was  executed  (figure 
12).  After  the  user  orogram  has  initially  been  executed/ 
the  execution  monitor  need  onlv  issue  a  CONTIN  system  call. 
This  system  call  puts  the  core  image  file/  which  is  current- 
ly blocked  for  processing/  back  on  the  system's  process 
ready  queue.  The  execution  monitor  then  issues  another  WAIT 
system  call  to  wait  for  the  next  interrupt.  The  execution 
monitor  returns  to  the  supervisor  monitor  only  when  the  job 
is  completed  or  a  breakpoint  h3S  been  encountered.  Figure 
15  illustrates  the  execution  monitor's  program  logic. 

5  .   D  i  soa t  c  her 

The  dispatcher  is  the  main  control  module  for  pro- 
cessing   virtual   machine   interrupts.   The   dispatcher   is 
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i  n  v  o  1  k  e  d  when  the  program  executing  on  the   virtual   machine 
executes  one  of  the  substituted  'TRAP*  instructions. 

The  dispatcher  determines  where  in  the  program  the 
interrupt  occurred,  the  type  of  interrupt,  (i.e.  breakpoint, 
sensitive  instruction,  or  normal  interrupt)  and  finally, 
what  simulator  or  function  to  call.  The  program  logic  is 
illustrated  in  figure  16. 
6.   Debug  Modules 

Plans  were  originally  made  to  use  the  debugging  pro" 
gramming  modules  of  UNIX,  but  unfortunately,  the  debugging 
program  modules  were  being  completely  revised  to  be  used 
under  MUNIX  so  the  decision  was  made  to  write  the  virtual 
machine  monitor's  own  debugger.  The  three  primary  modules  of 
the  debugger  are    the  display,  modify,  and  breakpoint. 

a .   Display 

The  display  module  is  used  to  display  the  virtu- 
al machine's  register  values  or  the  virtual  machine's  memory 
content.  (Display  commands  ere  outlined  in  Appendix  D.) 
Upon  command  of  the  user,  the  values  of  the  general  purpose 
registers  e>re  disolayed  both  in  octal  and  decimal  number 
representation  while  the  values  of  the  PS,  SP,  and  PC  are 
displayed  only  in  octal.  Memory  may  be  displayed  in  octal 
(core  dump  format)  or  symbolically.  In  either  case,  the 
memory  display  will  start  from  where  reouested  by  the  user 
for  the  number  of  words  specified*  Module  logic  flow  is 
depicted  in  figure  17. 

The  core  image  file  is  used  to  retrieve  the 
values   of   the   registers   and  the  octal  content  of  memory. 
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Thus  the  orooram  must  first  be  executed  (produces  a  core 
imeoe  file)  before  the  use  of  these  two  commands  are  al- 
1  owed. 

b .  Modify 

The  logic  flow  of  the  modify  module  (fiqure  18) 
is  similar  to  the  logic  of  the  previously  discussed  display 
module.  Memory  is  modified  by  the  modify  module  on  a  word- 
by-word  basis,  fis  was  in  display  module*  it  is  also  the  case 
here  that  the  program  must  first  be  executed  before  a  regis- 
ter is  modified.  Any  memory  modification  (memory  may  be 
modified  before  execution)  will  automatically  modify  the 
a. out  file  and  the  core  image  file  if  it  exists. 

c .  B  reakDoi  nt 

-The  breakpoint  debugging  facility  consists  of 
two  basic  functions.  One  function  (BPINSE.RT)  inserts  the  new 
breakpoint  into  the  user  program  and  the  second  function 
removes  the  breakpoint  when  executed  ( BPHANDLER ) . 

Up  to  ten  breakpoints  at  one  time  can  be  insert- 
ed into  the  program  and  can  be  entered  either  before  or  dur- 
ing execution  (For  breakpoint  commands  see  Appendix  D). 

The  BPINSERT  function  saves  the  instruction  at 
the  breakpoint  address  in  an  array  and  inserts  a  'TRAP' 
(104450)  instruction  in  place  of  it. 

rthen  the  breakpoint  is  executed  during  user  pro- 
gram execution  an  interruot  occurs  and  is  serviced  by  the 
BPHANOLR  (via  the  dispatcher).  The  real  instruction  is 
returned  to  the  pronram  and  the  program  counter  (PC)  is 
backed-up    one    instruction    to   point   to   the   returned 
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instruction,  A  rnessaqf>  is  printed  to  the   user   showing   the 
i 

instruction  address  and  instruction  where  the  breakpoint  was 
inserted.  Program  control  is  then  returned  to  the  supervisor 
m  o  n  i  tor. 

Breaknoints  are  removed  upon  execution  and  must 
be  re-inserted  upon  the  completion  of  a  breakpoint  interrupt 
each  time  the  user  desires  the  breakpoint  to  remain. 

The  BPINSERT  and  BPHANDLR  logic  flow  are  illus- 
trated in  figure  19. 

D.   TEST  AND  EVALUATION 

Several  small  standalone  programs  were  written  to  test 
the  reliability  and  performance  of  the  virtual  machine.  The 
testing  procedure  included  executing  the  program  on  the  vir- 
tual machine  ar><3    on  the  bare  machine  using  the  same  input. 

All  programs  tested  on  the  virtual  machine  executed  in  a 
similar  fashion  producinq  the  same  output  as  in  the  stan- 
dalone environment,  but  with  a  substantial  and  disappointing 
lost  of  efficiency.  For  example*  a  small  program  designee!  to 
echo  print  a  string  of  characters  had  immediate  response  on 
the  bare  machine*  but  took  up  to  twenty  seconds  oer  charac- 
ter on  the  virtual  machine. 

The  virtual  machine's  lack  of  efficiency  is  mainly 
caused  by  the  need  to  simulate  I/O  to  a  real  device*  the 
user  program  waiting  for  execution  in  the  process  queue 
aftPr  the  virtual  machine  monitor  has  completed  its  func- 
tion, and  the  need  for  updating  the  super-block  via  the  SYNC 
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system  call  (causes  all  information  in  core  memory  that 
should  be  on  disk  to  be  written  out)  to  insure  the  user  core 
file  is  located  on  the  disk  'swap'  area  before  the  virtual 
machine  monitor  can  access  the  orogram. 

The  efficiency  asoect  makes  the  virtual  machine  under 
its  current  design*  highly  impractical  for  serious  utiliza- 
tion, and  enohasizes  the  need  for  a  hardware  virtual  machine 
extension. 
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VI.   CONCLUSION 

The  virtual  machine  with  its  numerous  applications  pro- 
vides many  research  opportunities  for  an  educational  insti- 
tution. The  virtual  machine  has  proven  itself  as  an  extreme- 
ly valuable  tool  in  the  university  computer  laboratory*  in 
the  computer  science  classroom  as  an  effective  training  aid* 
and  in  the  business  world  as  a  sophisticated  approach  in 
solving  difficult  application  problems. 

Although  extremely  limited  in  its  current  stater  the 
PDP-11/50  virtual  machine  has  arrived  at  the  Naval  Postgra- 
duate School.  The  first  milestone  has  been  accomplished.  The 
basic  foundation  for  a  useable  virtual  machine  with  accom- 
panying debugging  aids  and  tools  has  been  completed.  The 
virtual  machine  will  execute  stand-alone  processes  that  corn- 
form  to  the  stated  restrictions.  Nevertheless*  a  great  deal 
remains  to  be  accomplished  to  produce  the  type  of  virtual 
machine  desired  and  needed  at  the  Naval  Postgraduate  School. 

In  our  s t u d y r  design,  and  implementation  of  this  limited 
virtual  machine  many  conclusions,  afterthouahts*  and  recom- 
mendations have  come  to  light.  The  following  highlights 
some  of  our  main  conclusions  and  thoughts. 

1.  Although  we  have  only  developed  the  embryo 
of  the  virtual  machine*  its  usefulness  is  readily 
apparent.  For  instance*  an  inexperienced  computer 
science  student  can  design  a  simple  assembler  pro- 
gram  and   actually   see   and  fellow  the  program's 
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execution  by  exarriininq  the  program  status*  memory/ 
and  registers.  he  can  r'a  p  i  d  1  y  obtain  an  under- 
standing of  data  representation  versus  instruction 
representation/  symbolic  language  versus  machine 
1  a  n  a  u  a  g  e  r  ana  memory  and  CPU  interaction.  Basic 
I/O  methods  con  also  be  explored. 

2.  Being  ambitious  is  an  excellent  personal 
trait/  but  trying  to  complete  a  new  house  with  a 
fancy  and  beautiful  exterior  before  the  foundation 
is  comoleted/  is  catastrophic.  A  great  deal  of 
time  and  effort  should  be  devoted  to  dividing  the 
problem  into  logical  pieces  of  workable  sizes. 
There  was  a  strong  desire  on  our  part  to  complete 
and  implement  a  virtual  machine  that  satisfied  the 
entire  school's  goals  for  v i rt ua 1 i zat i on.  At 
first/  much  time  was  spent  in  designing  some  of 
the  more  intricate  and  final  enhancements.  It  was 
with  great  effort  and  some  loss  of  pride  that  we 
limited  our  goals  and  establish  a  milestone  ap- 
proac  h . 


3.  Being  the  first  to  work  on  brand  new 
equipment  has  a  psychological  fulfillment/  but 
this  joy  is  quickly  diminished  on  encountering  the 
ever  present  new  hardware  bugs.  In  the  planning 
phase  of  new  a  p  d  1  i  cations  that  will  be  implemented 
on  new  hardware  (not  necessarily  unfamilar 
hardware)  'safety'  factors  should  be   incorporated 
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in  the  schedule.   At  worst  you  are  ore pared  and  at 
best/  you  finish  ahead  of  schedule. 

4.  Like  new  equinment,  unfami ! iarity  with  the 
language  adds  a  new  dimension  of  problems.  There 
is  a  substantial  learning  before  one  can  be  pro- 
ductive. This  takes  timer  effort/  and  continuous 
self-discipline/  but  is  absolutely  essential. 

5.  Many  enhancements  on  the  PDP-11/50  were 
being  accomplished  concurrently  in  a  coordinated 
team-group  aporoach.  A  marriage  of  advantages 
exists  in  this  type  of  real  world  working  environ- 
ment. Few  things  can  be  substituted  for  actual 
experience  in  a  hands-on  integrated  approach. 
Design  considerations  must  be  synchronized  with 
the  other  teams*  working  schedules  must  be  coord i  - 
natedr  and  joint  planning  meetings  must  regular  i 1 y 
be  attended.  (Jn  the  other  hand*  one  is  continually 
frustrated  by  files  being  destroyed?  system 
crashes?  unknown  system  changes,  and  lack  of  de- 
tailed coordination. 

6.  The  program  design  has  changed  consider- 
ably from  the  start.  It  is  extremely  difficult  to 
start  by  developing  programming  standards?  espe- 
cially when  the  language  and  its  characteristics 
are  unfamiliar.  Much  time  was  spent  on  reviewing 
the    proor<im    for    possible    regrouping     and 
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consolidating  proqram  modules. 

The  first  modules  were  qenerally  poorly  writ- 
ten/ caused  mainly  by  1  a  n  a  u  a  q  e  unfamiliarity  and 
the  desire  to  have  the  program  just  work.  As  pro™ 
grammina  skills  improved*  the  proqram  modules 
tended  to  become  more  soph i seated  and  clever*  and 
resulted  in  the  disguise  of  the  'loqic  flow.  This 
soon  'backfires'  on  any  program  of  considerable 
size.  Special  care  and  time  was  finally  taken  to 
improve  program  modularity*  clarity*  and  simplici- 
ty in  program  loqic*  especially  when  it  was  en- 
visioned that  later  enhancements  would  be  added  to 
the  proqrem  by  other  Drogrammers. 

The  use  of  variables  was  another  problem  area. 
They  must  be  controlled  from  the  beqinning  or  it 
will  quickly  be  too  late.  Variables  should  be 
organized  to  readily  distinguish  their  purpose  and 
should  incorporate  some  type  of  naming  conventions 
for  better  nrogram  control  and  maintenance. 

One  good  feature  of  the  proqram*  incorporation 
of  an  internal  proqramming  'debugger'  actuated  on 
command*  has  oroven  itself  extremely  useful  and 
va 1 uab 1 e. 

As  previously  mentioned*  there  is  no  'one  best  way'  to 
desiqn  a  virtual  machine*  however  access  to  various 
developed  ideas  and  alternatives  is  a  catalyst  for  futher 
research. 
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As  noted  throughout  this  thesis/  there  is  a  variety  of 
ongoing  activity  in  progress  thro  ugh  out  the  country  concern- 
ing the  virtual  machine  approach*  but  much  more  work  and 
educated  Drofessionals  are  needed.  The  future  of  the  virtu- 
al machine  at  the  Naval  Postgraduate  School  will  not  reach 
an  acceptable  level  without  careful  attention.  Many  areas 
remain  unresolved  including  the  possible  acguiring  of  the 
DLC  virtual  machine  extension  option  and  substantially  modi- 
fyinq  the  operating  system  to  alleviate  the  I/O  problem. 

Numerous  areas  of  research  in  virtual  machines  could  be 
recommended  for  futher-  research/  but  until  a  more  versatile 
virtual  machine  is  implemented  these  arts  will  have  to  wait 
or  be  accomplished  at  another  institution. 
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APPENDEX  A 
GLOSSARY 

The  purpose  of  the  Glossary  is  to  provide  a  brief  list 
of  the  more  com  mo  ft  definitions  found  in  this  thesis  and 
related  literature. 


1.  ARCHITECTURE!  -  Attributes  of  the  system  as  seen  by  the 
user.  It  is  the  functional  behavior  and  structure  of  the 
system  where  emphasis  is  olaced  on  the  needs  of  the  user. 

2.  BARE  MACHINE  -  M  a  c  h  i  n  fr  without  its  accompanied  software. 

3.  CONTROL  PROGRAM  -  Generally  means  virtual  machine  monitor. 

4.  EXTENDED  MACHINE  -  The  bare  machine  plus  operating  sys- 
t  em. 

5.  EMULATION  -  Technique  to  map  one  system  architecture 
into  another  different  architecture  using  some  type  of 
firmware  support.  Enables  the  computer  to  execute  instruc- 
tions of  other  computers. 

6.  FAMILY  -  Series  of  computers  with  similiar  architectural 
design  and  compat ab i 1 i t i es ,     i.e.  IBM  360  family. 

7.  FAMILY  VIRTUALIZING  -  Virtual  machine  not  identical  to 
the  host  but  is  a  member  of  the  same  computer  family. 

8.  GENERATION  -  Refers  to  the  architectural  characteristics 
of  the  computer,  i.e.  second  generation  and  third  generation 
computers. 

9.  HARDWARE  VIRTUALIZER  -  Hardware-firmware  virtual  machine 
monitor  that  supports  a  virtual  machine,  i.e.  distinct  from 
software  design  to  support  a  virtual  machine. 
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10.  HYBRID  VIRTUAL  MACHINE  -  All  instructions  in  the 
p  r  i  v.e  i  e  ge  d  state  are  software  interpreted.  All  others  are 
executed  directly. 

11.  HOST  MACHINE  -  Bare  machine  in  which  VMM  runs. 

12.  NATIVE  MQDF  -  Ooeration  of  system/  i.e.  no  emulation. 

13.  PRIVILEGED  INSTRUCTION  -  Instruction  that  must  execute 
only  in  the  privileced  mode  for  correct  results, 

14.  SELF-VIRTUALIZ1NG  -  The  processor  of  the  virtual  comput- 
er is  is  identical  to  the  host. 

15.  SENSITIVE  INSTRUCTION  -  An  instruction  which  if  permit- 
ted to  execute  directly  on  the  host  machine  will  give  in- 
correct results  because  of  the  virtual  machine  software  con- 
st rue  t  i  on  . 

16.  SUPERVISOR  CALL  -  Instruction  used  to  call  upon  the 
operating  system, 

17.  VIRTUAL  MACHINE  -  Isolated  duplicate  of  a  real  machine. 

18.  VIRTUAL  MACHINE  MONITOR  -  Software  which  mediates 
between  the  virtual  machine  and  host. 

19.  VIRTUAL  MACHINE  MONITOR  TYPE  I  -  Runs  on  a  bare  machine. 

20.  VIRTUAL  MACHINE  MONITOR  TYPE  II  -  Runs  under  the  host 
machine's  ooerating  system. 

21.  VIRTUALIZAT ION  -  The  creating  of  a  virtual  machine. 

22 .  VIRTUALIZABLE  -  Refers  to  being  able  to  create  a  virtual 
machine  from  the  existing  machine. 

23.  VIRTUAL  MACHINE  RECURSION  -  Ability  to  run  a  virtual 
machine  monitor-  on  a  virtual  machine. 
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PDP-11/ 50   CONFIGURATION 


u 
o   c 

•H    T3 
,C     U 

ft   c 

(0     'J 
u     i) 


woo: 


a.  a, 


a>  o 


O 


£ 


X    o 


u 
.c 

13  >. 

U  ro 

Cn  <H 

O  0, 

C  10 

O  -H 

U  Q 


X 

■H 

c  >, 

O  f0 

M  .-( 

■P  ft 

a:  0) 

£h  Q 


sna  Avidsia 


i 

■4 

c 

J     <D 

c;  c 

^    A 

H     r 

3     ,0 

a  c 

n    H 

< 


0 


sna  NoinsinSDv  viva 


^ 

cj 

X 

a 

^) 

i-i 

>~i 

ft 

o 

•h 

ft 

4J 

rH 

W) 

3 

.H 

t3 

M 

i-l 

CJ 

a> 

-P 

TJ   13 

c 

V-l      13 

•H 

<TJ     0) 

M 

UPS 

ft 

CO 

■a 

c 

2£ 


in  a< 

cm    w 


85 


APPENDIX  C 

SENSITIVE  INSTRUCTIONS 

The  following  PDP-11/50  machine  instructions  were  deter- 
mined sensitive.  The  determination  was  based  on  the  Premise 
that  if  the  instruction  were  allowed  to  be  executed  either 
(1)  the  current  state  of  the  virtual  machine  would  be  inac- 
curate and/or  (2)  that  the  instruction  would  unite ntionallv 
interfer  with  and/or  return  to  the  real  system.  It  should  be 
noted  that  some  of  these  instructions  are  only  sensitive  due 
to  the  approach  selected  for  producing  and  operating  the 
v  i  r t  ua 1  mac  h  i  ne . 

GROUP  1.  -  These  are  the  instructions  that  if  exe- 
cuted would  trap  to  the  real  system  for  interrupt 
handling  instead  of  to  the  virtual  machine  inter- 
rupt handl ers . 

1.  HALT  -  Generates  an  interrupt  in 
user/supervisor  mode?  traps  to  physical 
address  4 . 

2.  BPT  -  Breakpoint  interuptf  trans  to 
physical  address  14. 

3.  I0T  -  I/O  interrupts  traps  to  physi- 
ca 1  address  20 . 

4.  EMT  -  Emulator  interrupts  traos  to 
physical  address  30. 

5.  TRAP  -  Trap  interrupts  traps  to  phy- 
sical address  i  4  . 
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GROUP  IT  -  These  are  the  instructions  that  if  exe- 
cuted would  automatically  change  the  program 
Status  word  (PS).  This  action  must  be  simulated^ 
in  a  virtual  interupt  changing  only  the  virtual 
PS. 

1.  RTI  -  Return  from  trap. 

2.  PTT  -  Return  from  trap. 

3.  WAIT  -  It  causes  the  processor  to 
relinquish  use  of  the  UNIX  and  wait  for 
an  external  interrupt. 

GROUP  III  -  These  instructions  are  designed  for 
inter-mode  communication  using  the  memory  manage- 
ment unit.  A  virtuali zed  memory  management  unit 
is  required  for  this  instruction  set. 

1.  MFPD  -  Move  from  previous  data  space. 

? .  MTPD  -  Move  to  previous  data  space. 

3.  M  F  P I  -  Move  from  previous  instruction 
soace . 

4.  MTPI  -  Move  to  previous  instruct  ion 
soace . 


GROUP  IV  -  These  instructions  ere  NOPs  in  the 
user/suoervisor  mode  and  should  reflect  a  change 
in  the  state  of  the  virtual  machine. 

1.  RtSET  -  All   devices   on   UNIBUS  are 
reset  . 

2.  SPL  -  Sets  a  new   priority   level   in 
the  PS. 
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GROUP  V  -  Miscellaneous  instructions. 

1.  '^OV  -  This  refers  to  any  MOV  instruc- 
tion that  references  the  I/O  page.  This 
instruction  is  sensitive  only  due  to  the 
restriction  placed  on  the  I/O  process- 
i  ng. 
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APPENDIX  D 

USERS  MANUAL 
FOP  THE 
PDP-11/50  VIRTUAL  MACHINE 


I.  PURDOSE 

This  users  manual  is  primarly  designed  to  explain  how  to 
execute  programs  on  the  virtual  machine  and  how  to  use  the 
virtual  machine's  debugging  capability. 

II.  VIRTUAL  MACHINE 

1.  Virtual  Machine  -  What  it  is 

A  virtual  machine  is  basically  a  software  orogram 
which  creates  the  i  maae  and  environment  of  a  bare  machine  (a 
PDP-11/50  without  an  operating  system).  Programs  that  nor" 
mally  execute  on  a  real  bare  machine  will  execute  on  the 
virtual  machine. 

2.  Function 

The  virtual  machine  has  been  used  in  many  soohisti- 
cated  apolications  in  the  computer  processing  world.  One  of 
these  usesr  and  the  primary  one  for  this  machine?  is  an  edu- 
cational aid  for  the  student  in  computer  science. 

Here  the  student  has  his  own  bare  PDP-11/50  computer 
to  program  and  examine  the  program's  execution,  The  virtual 
machine  will  execute  stand -alone  PDP-11/50  assembler  pro- 
grams that  meet  the  restrictions  in  section  VII, 
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3.  Debugaing  Capability 

The  virtual  machine  has  a  simple  but  significant 
debugging  capability.  The  student  can  display  and  modify 
the  general  ourpose  registers/  program  counter/  stack 
pointer/  and  program  status  word.  He  can  also  diSDlay  and 
modify  memory.  He  can  insert  breakpoints  at  certain  areas 
of  his  program  for  controlled  program  execution. 

4 .  Configuration 

The  virtual  machine's  configuration  is  as  follows: 

a.  One    PDP-ll/bO    computer   (without   memory 
management ) . 

b.  32k  words  of  memory. 

c.  One  L  A  3  0  DECwriter  terminal. 

III.  INPUT  TO  THE  VIRTUAL  MACHINE 

Jobs  to  be  processed  on  the  virtual  machine   must   con- 
form to  the  following  characteristics.   They  must: 

1.  be  PDP-11/50  assembly  programs. 

2.  be  in  a. out  file  format. 

3.  have  non-shareable  program  segments. 

4.  not  incorporate  any  UNIX  system  calls, 

5.  have  been  preprocessed  by  the  virtual  machine  moni- 
tor. 

IV.  GENERAL  FLOW  IN  USING  THE  VIRTUAL  MACHINE 


1.   Programmer  designs/  programs/  and  assembles  his  pro* 
gram. 

2..       User  starts  up  the  program  '^vm™1. 
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3 .  User  preprocessors  his  assembled  program  using  the 
preprocessor  command  of  the  virtual  machine. 

H •  Program m err  may  if  he  desires*  insert  breakpoints 
into  his  orogram  at  critical  areos. 

5.  User  executes  his  program  using  the  execute  command 
of  the  virtual  machine. 

6.  Programmer  can  at  anytime  while  his  job  is  not  actu- 
ally executing  on  the  virtual  machine*  utilize  any  debug 
f unct  i  on. 

7.  when  program  has  terminated*  user  can  stop  the  vir- 
tual machine  by  the  termination  command. 

V.   VIRTUAL  MACHINE  COMMANDS 

The  following  is  a  list  of  the  valid  commands  and  their 
resoective  functions.  All  addresses  (ADDR)  and  reguired 
values  (VALUE)  must  be  expressed  in  octal. 

COMMAND  FUNCTION 


p  f  i 1  ex  [y/n] 


Preprocess  filex.  This  com- 
mand has  one  optional  parame- 
ter. The  parameter  indicates 
whether  the  user  wants  to  be 
informed  when  a  sensitive 
instruction  is  encountered. 


Start  or  continue  program  exe- 
cution. 


b   ADDR 


Put  a   breakpoint   at   address 
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d   p 


d   o   ADDR  n 


d   s   ADDR  n 


m   rX   VALUE 


m   SP   VALUE 


m   PC   ADDR 


m   PS   VALUE 


m   mem   ADDR   VALUE 


ADDR 

Display  all  general  register 
plus  the  program  status  word. 

Display  memory  starting  from 
address  ADDR  for  U  number  of 
words . 

Display  the  program  symboli- 
cally from  address  ADDR  for  # 
number  of  instructions. 

Modify  register  X  to  VALUE 

Modify  stack  pointer  to  VALUE. 

Modify  the  program  counter 
with  address  ADDR. 

Modify  the  program  status  word 
to  VALUE. 

Modify  memory  at  address  ADDR 
to  VALUE. 

Terminate  the  execution  of  the 
virtual  machine  monitor. 


VI.  PREPROCESSOR 

The  preprocessor  examines  the  user's  programs  for  sensi~ 
tive  instructions  (instructions  that  can  not  be   allowed   to 
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directly  execute).  As  illustrated  above  in  the  virtual 
machine  commands/  the  preorocessor  has  two  parameters.  The 
first  parameter  is  manditory  and  is  the  user's  program  name/ 
the  second  oarameter  is  optional ,  allowing  the  user  a  choice 
of  whether  he  wants  to  be  notified  when  a  sensitive  instruc* 
tion  is  encountered.  When  notification  is  desired/  the  sen- 
sitive instruction  plus  the  five  previous  instructions  of 
the  program  and  their  location  will  be  displayed.  After 
examining  these  instructions  the  user  can  agree  or  disagree 
with  the  oreprocessor.  The  user's  decision  is  accepted  by 
the  preprocessor  so  user  BEWARE. 

The  'JSR'  and  'TRAP'  instructions  have  the  possibility 
of  having  a  variable  number  of  parameters  following  them 
(these  parameters  frequently  look  like  sensitive  instruc- 
tions to  the  preprocessor).  Because  of  this  unigue  charac- 
teristic/ the  preorocessor  will  automatically  printout  the 
five  previous  instructions/  the  'JSR'  and  'TRAP'  instruction 
encountered/  and  a  message  requesting  the  number  of  parame- 
ters that  are  following  the  instruction.  The  user  can  then 
indicate  to  the  preprocessor  the  number  of  parameters  to 
skip. 

VII.  BASIC  RULES  AND  RESTRICTIONS 


1  „  All  files  must  be  an  a. out  file  and  be  preprocessed 
before  any  command  will  function  on  the  virtual  machine 
including  file  execution. 

2 .  All  files  will  be  stand-alone  type  processes/  and 
must   not   use   any   UNIX   system   calls  (READ/  WRITE/  EXIT/ 
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LTC). 

3.   Files  cannot  employ  any  interrupt  type  processing. 

'4 .  Files  must  perform  their  own  I/O  routines.  I/O  is 
restricted  in  the  method  used  to  access  the  I/O  page.  All 
access  to  the  I/O  page  will  be  performed  only  by  the  'MOV' 
instruction?  and  then  only  by  direct  indexing.  I/O  access- 
ing is  limited  to  the  four  LA30  DECwriter  registers.  (see 
DEC  peripherals  handbook). 

5.  File  must  first  be  executed  before  displaying  or 
modifying  registers*  or  in  displaying  memory  in  octal. 

6.  Files  will  use  the  'HALT'  instruction  for  normal 
exiting  from  their  program. 

7.  The  following  assembler  instructions  will  be  treat- 
ed as  NOP  instructions:  MFPD,  MTPD,  MFPI,  MTPI,  RESET,  WAIT* 
RTI,  RTT,  and  SPL. 

8.  The  user  should  be  cautioned  against  inserting  a 
breakooint  within  an  I/O  (loop)  routine  that  inputs  a  string 
of  characters.  when  a  breakpoint  is  encountered  the  remain- 
ing characters  for  insertion  will  be  lost. 


VIII.  FILE  NAMES  AND  FUNCTION 

1  •   '  *-  v  m  m  '  -  Name  of  the  virtual  machine  monitor   pro- 
gram the  initially  creates  and  controls  the  virtual  machine. 

2.  't-vmpOOl'  -  Name  of  the  preprocessor  program. 

3 .  '  *-  v  m  m  0  0  2  *   -   Name  given  to  the  user  program  after 
user  program  is  is  modified  by  the  oreprocessor . 

4  «   '  *-  v  m  t  0  0  3  '  -  An  array  of  sensitive  instructions  and 
addresses  in  the  user  program  by  the  preprocessor. 
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